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
        if (this.IsValued)
            _accepted = new SolidColorBrush(Colors.DarkGreen);
            _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);
            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.

1 Answer 1


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.


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}"/>
  • 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
    Commented Sep 12, 2016 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
    Commented Sep 13, 2016 at 5:35
  • This. Also, if all you are doing is setting colors, you should be using styles and triggers instead of converters.
    – Euphoric
    Commented Sep 13, 2016 at 6: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
    Commented Sep 13, 2016 at 6: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 _acceptedin the setter is completely ignored in the getter? Sure about this?
    – Doc Brown
    Commented Sep 13, 2016 at 6:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.