What's the different between MVVM and MVP pattern

Sep 28, 2009 at 3:05 AM

Besides the Command binding in MVVM, other actions in MVVM and MVP are very similar .

The ViewModel in MVVM is like the Presenter in MVP pattern .

Could someone point me out what's the obviously differences of these two architecture ?

Thanks .

Oct 7, 2009 at 5:38 PM

According to my understanding...

In MVVM:

  • View is aware of ViewModel (because a View generally has data bindings and commands to the ViewModel)
  • ViewModel is aware of Model (because a ViewModel generally holds a reference to the Model as a private field)
  • ViewModel is not aware of View
  • Model is not aware of ViewModel
  • View and Model are not directly aware of each other (although some bind their View to static, non-changing data directly to the model).

In MVP:

  • Presenter is aware of the View (because the Presenter can control the view via a defined IView interface)
  • Presenter is aware of the Model (because a Presenter generally holds a reference to the Model as a private field)
  • The level of awareness between the different pieces depends on if it's the Passive View flavor or Supervising Controller flavor of MVP.

Some implications:

  • In MVVM, since the viewmodel knows nothing of the view, you can swap out the view with a completely different view without any effect to the remainder of the application. (In MVP, the presenter has to know what the view is so that it can control it, so when a view is replaced, the presenter has to be updated.) Big benefit for MVVM here is the ability to unit test - one can replace the view with a simulated view, the unit test harness. The test harness reads the properties of the viewmodel, which is what a view would bind to, and the test harness can call methods on the viewmodel, which is what a view would do via the commands.
  • In MVP, the presenter is responsible for keeping the state of the view in sync with the state of the model, and vice versa. In MVVM, the viewmodel is an abstraction of the view itself so the state of the view is actually maintained in the viewmodel.

I wish there were some better language to describe this more clearly -- even I get frustrated that there aren't better ways to illustrate this sort of stuff.