C# WPF MVVM – Alternatives to ObservableCollection

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.

It's the same approach as with any other major refactoring.

1. Built unit tests to validate the behavior of the existing code.

2. Identify and isolate small sections of code that can be refactored.

3. Refactor one section at a time.

4. Verify that all unit tests (see step 1) continue to pass. If they fail, fix your refactoring.

5. Rinse and repeat until you regret the day you ever decided to refactor the code base.

6. Eventually you'll complete the refactoring. Swear off code-behind and promise yourself that you'll never, ever make those mistakes again.

As far as how to separate out business logic from UI logic within MVVM. For the most part, all of your business logic should live at your Model layer or lower. All UI related logic, including properties to be bound to, will live at the View and ViewModel layer.

A good rule of thumb on "Is it business logic or UI logic" is the following. If the behavior of the code should persist regardless of what the UI is, that's business logic. If the code's behavior is tied to the presentation of the data, that's UI logic.