In the model tier, I have defined an enum:
public enum MemberStatus
{
ActiveMember = 0,
InactiveMember = 1,
Associate = 2,
BoardMember = 3,
Alumni = 4
}
In my view, I have a combo box that is populated with those enum values:
<UserControl.Resources>
<ObjectDataProvider
x:Key="memberStatusesDataProvider"
ObjectType="{x:Type system:Enum}"
MethodName="GetValues">
<ObjectDataProvider.MethodParameters>
<x:Type TypeName="model:MemberStatus" />
</ObjectDataProvider.MethodParameters>
</ObjectDataProvider>
</UserControl.Resources>
...
<ComboBox
ItemsSource="{Binding Source={StaticResource memberStatusesDataProvider}}"
SelectedItem="{Binding Path=Status}" />
...
This results in getting the combo box with the choices that are exactly the same as values defined in the enum. Although that was my initial goal, I want nicer presentation for the user, something like this:
Also, if the language in the application changes, I need the enum values in that language. To tackle this, the first thing that came to my mind is to create a converter for MemberStatus
enum values. I found this beuatiful article on the topic: http://www.codeproject.com/KB/WPF/FriendlyEnums.aspx But MVVM pattern says that there should be no need to create them almost at all - and I agree with this. However, this affirmation does not work in my favor in this example.
How is it supposed to be done? Thanks.
The view that MVVM makes value converters obsolete appears to have come from Josh Smith who says in his blog post The Philosophies of MVVM:
... a ViewModel class is essentially a value converter on steroids, thus rendering the IValueConverter interface irrelevant for most bindings.
What I take from that (and I agree with him for what it is worth) is the the View Model is responsible for all conversion from the Model's view of the world to the Views, rendering the converter obsolete.
Having an enum (which is a very data centric data type) in the Model exposed up to the UI is definitely a smell - if only for the reason you see, of showing less than ideal information to the user.
Put a mapping from enum to UI string in your View Model.
Converters are useful for way more than converting enum
s. Converters are also more reusable than a one-off viewmodel
is.
I might want to convert a bool
to a Brush
and I can specify the parameters all in the view.
Or maybe I want to convert a string
to DateTime
and back again all via data binding. Maybe I want to convert everything to upper case. Then there is my favourite BoolToVisibilityConverter.
I'd hate to put explicit direct or indirect code all throughout my VM
s just to keep some minority groups happy. The thing I would argue they forget is that converters are easily accessible from Expression Blend.
Converters are an essential part of WPF and suppliment binding between view
and viewmodel
.
I see no reason why you can't use them for enum
s.
MVVM is not really set in stone as to what parts of WPF are and are-not allowed. Converters are fine to use if they accomplish your goal easily. I would even suggest taking it a step further and making a MarkupExtension
to supply the enum values and their string equivalents. You could store the strings in a DescriptionAttribute
on each enum value.
I don’t agree that MVVM does make ValueConverters obsolete. There are more than enough scenarios where implementing a ValueConverter makes more sense as implementing the conversion in the ViewModel class.
You might be interested in the BookLibrary sample application of the WPF Application Framework (WAF). It shows how an enum can be localized in a MVVM application. Please have a look at the BookLibrary.Presentation / Converters / LanguageToStringConverter class.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With