Using a Non-Anemic Domain Model with Wpf MVVM

Here is how I usually deal with it:

1. The ViewModel layer is made of types that belong to this layer, meaning I don't ever directly use my business objects inside of a ViewModel. I map my business objects to ViewModel objects that may or may not be the exact same shape minus the behaviors. It can be argued that this violates Don't Repeat Yourself, but doing so allows you to adhere to the Single Responsibility Principle. In my opinion, SRP should usually trump DRY. The ViewModel exists to serve the view, and the model exists to serve business rules / behavior.

2. I create a facade/service layer that takes and returns ViewModels as arguments, but maps the ViewModels to-and-from their corresponding business object versions. This, way the non-anemic objects won't impose non view logic on the ViewModel

The dependencies would look like this:
ViewModel <--> Facade/ServiceLayer --> Business Objects

I think it is important to keep this in mind if you want to unleash the full potential of MVVM: The ViewModel is the model/abstraction of the view, not the model presented to the view.

Try using Command pattern. Your screen should be design not to edit an entity but to perform an action (command) on an entity. If you follow that principle when designing your screens, your ViewModel will have properties that should be mapped to a command object. Then, the command will be send to an (remote) facade of the domain model.

ViewModels for displaying the data could be mapped directly to the database (bypassing the domain model altogether) so that you don't need to put nasty getters in the domain model classes.

If the domain model is non-anemic, you will need to use events to communicate internal changes in the Model back to the ViewModel. That way you don't have to worry about keeping track of what operations could potentially make your VM out-of-sync with the model.

Here's a simple example:

First, a sample model:

public class NonAnemicModel{    private string _name;    public string Name    {        get { return _name; }        set        {            if (_name == value)                return;            _name = value;            OnNameChanged(EventArgs.Empty);        }    }    public event EventHandler NameChanged;    protected virtual void OnNameChanged(EventArgs e)    {        if (NameChanged != null)            NameChanged(this, e);    }    public void PerformNameCalculation(int chars)    {        //example of a complex logic that inadvertently changes the name        this.Name = new String('Z', chars); //makes a name of Z's    }}

And here's a sample ViewModel:

public class MyViewModel : INotifyPropertyChanged{    private NonAnemicModel _model;    public NonAnemicModel Model     {        get { return _model; }        set        {            _model = value;            _model.NameChanged += (sender, args) => NotifyPropertyChanged("UserName");        }    }    public string UserName     {        get { return this.Model.Name; }        set { this.Model.Name = value; }    }    //this command would call out to the PerformNameCalculation method on the Model.    public ICommand PerformNameCalculation { get; private set; }}

Notice that the PropertyChanged event is raised when the Name on the model changes. That way, regardless of whether the UserName setter was used, or the PerformNameCalculation command was used, the ViewModel stays in sync. The big downside to this is that you have to add many more events to your Model, but I've found that having these events in place is usually very helpful in the long run. Just be careful about memory leaks with events!