WPF, MVVM, EF, POCO guidance required on simple architecture

Question

(sorry for my poor english) I am developing a application using WPF, EF Code First using MVVM (Caliburn.Micro). It should be used mostly to CRUD work. I created a BaseViewModel<T> class from wich all other ViewModels inherit and exposed a T Selected property to bind to the View. I know it is not recomended to expose a Model to the View but it just make things simple to get the app running.

Problem is I do not want to pollute my Models (EF POCO classes) with INotifyPropertyChanged, IDataErrorInfo, IEditableObject, etc... So, there is something that I can do here or do I have to really duplicate all Model properties to the ViewModel and give up trying to bind the model directly? I would like to use the attribute validation too, since all models have them already.

I used this approach on the past with Silverlight/RIA but in this case RIA Services generated the classes for me, with all the plumbing code.

I can get the validation errros using Validator class but I also need to indicate the component that has the error no the UI and I think I need to implement IDataErrorInfo on my model for this to happen, right?

For INotifyPropertyChanged I can use something like NotifyPropertyWeaver but my problem is IEditableObject and something to be able to use the attribute validation. It would be nice something like MagicBusinessBaseClassThatImplementAllThoseInterfaces<Model> to encapsulate the model so I can just bind it and move on.

I know I can make this work implementing manually the interfaces on each VM - but just think on all the "duplicated" code make me cringe :(

How WPF developers are doing those kind of things today? There some secret ninja technique that I am not aware of?

Answer 1

Personally I see nothing wrong with binding directly to the Model instead of exposing properties through the ViewModel, however if you plan on binding to your EF POCO classes, you need to have them implement INotifyPropertyChanged so the UI knows when they update.

EF should have a setting that will make it generate the classes with INotifyPropertyChanged already implemented, however you will still have to do something custom to get IDataErrorInfo to work the way you want (I recommend using IDataErrorInfo instead of the Validator class when working with WPF because the XAML is already setup to use that interface for errors). Usually I'll create partial classes for each data model that needs validation that implements IDataErrorInfo, although I know other methods do exist that may work better for you.

Another alternative I've used in the past is to create another layer entirely for the Models, and not use EF models at all other than in the database layer. I think last time I did this, I modified EF's T4 template to autogenerate my Models at the same time the EF POCO objects were generated, with the exact same data structure, and I used AutoMapper to map EF objects to my Model objects whenever a database call was made.

And of course, there's also the 3rd alternative you mentioned of simply exposing the properties from the ViewModel, and not binding to the Model at all. This is the "MVVM-Purist" way of doing it, but its often not as practical since it requires more time to implement.