Get/Set Property in a Class vs IValueConverter

Question

So i've been going through some of my old code from the time i was learning the basics of wpf and i found something intresting.

I had a class in the format below

public class TempClass
{
    public bool IsValued { get; set; }
    private SolidColorBrush _isValuedColour;
    public SolidColorBrush IsValuedColor
    get
    {
        if (this.IsValued)
        {
            _accepted = new SolidColorBrush(Colors.DarkGreen);
        }
        else
        {
            _accepted = new SolidColorBrush(Colors.Transparent);
        }
        return _accepted;
    }
    set { _accepted = value; }
}

If you see, I created a SolidColorBrush based off my IsValued Property to return a Color Property. This code was from 2013 and I believe I started learning in this way maybe because of the websites that i was going through to learn xaml

Come 2015 I checked another project and noticed that I started using IValueConverter I was able to achieve the same without creating a new property.

<Button Foreground="{Binding IsValued, Converter={StaticResource boolConverter}}">

and here is my Implementation.

class BoolToColorConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, string language)
    {
        SolidColorBrush brush = new SolidColorBrush();
        if ((bool)value)
        {
            brush = new SolidColorBrush(Colors.Gold);
        }
        else
        {
            brush = new SolidColorBrush(Colors.Transparent);
        }
        return brush;
    }

    public object ConvertBack(object value, Type targetType, object parameter, string language)
    {
        throw new NotImplementedException();
    }
}

While both does the job for me, i would like to know which route is better. Is creating new property with getters and setteres a good way or using converters a good way?

Thanks for enlightening me.

Philippe · Accepted Answer · 2016-09-13T06:00:05.770

4

If it's a presentation concern, go the converter way.

If it's a business concern, add a property to the domain object.

A color is almost always a presentation concern. It could be a domain concern if the exact color has a deep meaning to the business.

So I'd go the converter way unless I have a very specific reason to have the color in the domain.

Update

On a coding methodology point of view, this is an application of the Single Responsability Principle, the S in SOLID. The view should only change when the specification of the presentation changes, the business object should only change when the business rules change.

If the color is part of the business rules, a change in the color specification must change the business object, so the color is a getter in the business object.

Normally, you have to change the view (and not the converter). Usage of some reusable bool-to-value converter should allow this:

<Brush x:Key="GoldBrush">Gold</Brush>
<Brush x:Key="TransparentBrush">Transparent</Brush>
<controls:BoolToValueConverter x:Key="xxxColorConverter"
    TrueConvertValue="{StaticResource GoldBrush}" 
    FalseConvertValue="{StaticResource TransparentBrush}"/>

edited Sep 13 '16 at 06:00

answered Sep 12 '16 at 19:40

Philippe

569
2
5

Thanks for the answer but my question is nether from a presentation concern nor from business model concern. I am looking for Performance, usability and correct coding methodology in a scenario where coding plays an important role irrespective of end UI result. – AVK Sep 12 '16 at 21:12
2

The difference in performance is negligible, and usability isn't a concern here as is doesn't change the UI at all. I'll update my answer to better show how it relates to coding methodology. – Philippe Sep 13 '16 at 05:35
This. Also, if all you are doing is setting colors, you should be using styles and triggers instead of converters. – Euphoric Sep 13 '16 at 06:11
@AVKNaidu: "my question is neither from a presentation concern nor from business model concern" - what makes you believe so? "Correct coding" can perfectly mean to make a decision by your knowledge of the layer where you are applying the change. So where is your `TempClass` - in the business layer or in the presentation layer? – Doc Brown Sep 13 '16 at 06:14
@AVKNaidu: ... by the way, the implementation of your `IsValuedColor.get` property looks strange - get has a strange side effect to `_accepted`, and whatever is assigned to `_accepted`in the setter is completely ignored in the getter? Sure about this? – Doc Brown Sep 13 '16 at 06:18
@DocBrown Going back to my first ever project that I did while learning wpf in 2013, i can say lot of things about my code is strange. I had `TempClass` in MainPage.xaml code behind in the project from which i posted my first example. Pretty dumb move. – AVK Sep 13 '16 at 11:20

Get/Set Property in a Class vs IValueConverter

1 Answers1