Question

In WPF it’s better to create a property “complex” (i.e. of type “Visibility”) or a property simple (i.e. of type boolean) and then using a converter to bind the property? The first way is shorter to write, but I don’t know what is better about the performances.

Answer 1

The performance hit of using a converter is going to be negligible. What you should base the choice on, though, is where you’re implementing the property.

A Visibility property only makes sense on a class in the UI layer (a custom control or maybe a viewmodel). If you’re creating a property on a model class that just happens to drive your UI in this instance, it would make more sense to use a boolean and a converter.

EDIT: added (slightly contrived) example

For example, imagine you have a data class (a model) for an editable object called Foo, and a Foo can be “simple” or “advanced.” An “advanced” Foo will display extra editing controls in the UI – so we need to bind the Visibility property of the advanced edit panel to some property.

Your Foo class could have a property to indicate whether it’s advanced or not. That property should definitely be a boolean – NOT a Visibility – because your Foo class shouldn’t care about any specifics of the UI that’s displaying it. So a boolean Foo.IsAdvanced would be a suitable property.

In this case, you could bind directly to Foo.IsAdvanced and use a converter. What you definitely don’t want to do is create a Visibility property Foo.AdvancedEditControlVisibility, because Foo is supposed to be back-end data class.

If you wanted to create a property that doesn’t require a converter, you should create that property in a higher class, one specific to your UI. Some architectural patterns would call this a “ViewModel” class – it’s a class that presents the model in a way that the data is more suitable for display by the UI. So, you might create a class that takes a Foo and exposes an AdvancedEditControlVisibility property that is based on the value of its Foo.IsAdvanced.

In this case, you could bind directly to the property on the viewmodel with no converter. Note that ultimately you’ve done the conversion anyway – you’ve just made it a more explicit part of your code, instead of being confined to markup.

The thought process here is that the viewmodel is a “higher level” class – one that wraps your data class and includes UI-specific logic – and so it’s more appropriate to include code that is specific to your UI. Ideally, you should take each class of your project in turn and make sure that it has a specific purpose: if Foo is a business-object that holds data, why should it expose (or even care about!) the visibility of some piece of UI used to display it? What would happen if you put a Foo in a commandline app, or a web application? If you have WPF-UI-specific logic in a business class then your encapsulation is wrong – but separation of concerns in this manner is one of the hardest things to get right sometimes.

And performance-wise you’ll notice little difference. 🙂