There is an underlying premise to presenter that implies a tighter coupling for the state of the presenter to the view. It's not unusual for the presenter to reference the view and the view to bind to state on the presenter. The presenter also provides behavior to the view, responding to events and such. With WPF, the advanced forms of data binding it provides can eliminate the need for code to control behavior. A lot of behavior can now be described in state as XAML. The view model eliminates any notion of behavior control, and is a simple layer of data over the model. The view model becomes the data context for the template controls, and the controls themselves will interpret this state and may even fire off commands to services "somewhere out there." In many cases in WPF if you have a presenter, your may find it devoid of anything useful and your view and view model classes just full of property fields.