EF4 + MVVM - Expose entities in ViewModel?

Question

I've played around with some different implementations of Model-View-ViewModel and consistently come across a situation where I am not sure of the correct way to proceed. I know one of the goals of MVVM is to decouple the View from the application logic so that the logic can be tested without the presence of a View. Putting the logic in a ViewModel which has no dependencies on the View solves this problem. Great. Even better if the Model can be decoupled from the ViewModel in such a way that it can be mocked.

So my question is, should the ViewModel decouple the Model from the View? In other words, is it "ok" to expose EntityFramework entities to the View through the ViewModel? For example, say there is a combobox in the view where the user can choose a State for an address. In the AddressViewModel, should State be exposed as a real entity-type property, or should it be exposed as a StateViewModel? If it should be a StateviewModel-typed property, I don't understand how the underlying model should be managed within the AddressViewModel.State setter (because what is being set in the property is a StateViewModel and not a State entity).

It seems to me that this could go either way, but seems more consistent to never expose the model directly to the view. Thoughts?

Answer 1

You should strive to completely decouple your model from your view, this should be a goal, you might meet it, or you might not, but still that should be your goal.

Specifically your question deals with a list of constants (more or less), which is an easy case. Correct me if I'm wrong here, but you probably have a States table with a code and a name for each state, and then you have another table with a foreign key to the former.

In this scenario it is best to load up and create the StateViewModel list once during application initialization, and then deal with the foreign key value (the state code as it were) throughout the application instead of the StateViewModel objects themselves. The properties you should use are the SelectedValue and SelectedValuePath of the ComboBox, example:

<ComboBox ItemsSource="{x:Static StateViewModel.StaticList}"
          SelectedValue="{Binding StateForeignKey}"
          SelectedValuePath="code"
          DisplayMemberPath="name" />

This will populate the ComboBox with StateViewModel objects (which were created using a now-disposed context), but will pass the selected item's code property on to the bound field StateForeignKey, additionally, the ComboBox will display the name property so that it's human-readable.

Answer 2

The purpose of the view model is to decouple the view from the data model. If there's no functionality in the view that's coupled to the data model, no view model is necessary.

If you have an object in the data model whose properties don't change after it's created, and that the view is not going to modify, and that can be presented in the UI without formatting or conversion, then you're not coupling any of its functionality to the view by exposing it directly. You don't need a view model for this.

In your example, you probably can get away without creating a StateViewModel class, since such a class wouldn't really do anything.