Read my earlier post - http://arun-ts.blogspot.jp/2010/12/mvvm-silverlight.html
MVC –, 1979
MVP – Model-Model-View-ControllerView-Presenter, 90s
Modern MVVM – Model-View-ViewModel, 2005
General rules for when to use which?
MVP
- Use in situations where binding via a datacontext is not possible.
- Windows Forms is a perfect example of this.
- In order to separate the view from the model, a presenter is needed. Since the view cannot directly bind to the presenter, information must be passed to it view an interface (IView).
MVVM
- Use in situations where binding via a datacontext is possible. Why? The various IView interfaces for each view are removed which means less code to maintain.
- Some examples where MVVM is possible include WPF and javascript projects using Knockout.
- MVVM separates the presentation part and business logic. This leads to:
- Higher testability
- Higher maintainability
MVC
- Use in situations where the connection between the view and the rest of the program is not always available (and you can't effectively employ MVVM or MVP).
- This clearly describes the situation where a web API is separated from the data sent to the client browsers.
- Microsoft's ASP.NET MVC is a great tool for managing such situations and provides a very clear MVC framework
Model-View-Presenter
<![if !supportLists]>1. <![endif]>In MVP, the Presenter contains the UI business logic for the View.
<![if !supportLists]>2. <![endif]>All invocations from the View delegate directly to Presenter.
<![if !supportLists]>3. <![endif]>The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. I.e. The Presenter is not responsible for determining which View is displayed in response to any action including when the application loads, instead specific view instance is passed to the Presenter on the load of the view.
<![if !supportLists]>4. <![endif]>Here View has a reference to Presenter (But completely decoupled from each other's and communicate to each other's by an interface) but View has no reference to Model.
public partial class Views_add_category_view : System.Web.UI.UserControl, IAddCategoryView
{
protected void Page_Load(object sender, EventArgs e)
{
presenter = new AddCategoryPresenter(this);
}
}
One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed.
Imp: MVP tends to be a very natural pattern for achieving separated presentation in Web Forms. The reason is that the View is always created first by the ASP.NET runtime.
Two primary variations of MVP
Passive View: The View is as dumb as possible and contains almost zero logic. The Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. +
The Model may raise events, but the Presenter subscribes to them for updating the View.
Similarly View exposes setter properties which the Presenter uses to set the data in the Model.
All state is managed in the Presenter and not the View.
- Pro: maximum testability surface; clean separation of the View and Model
- Con: more work (for example all the setter properties) as you are doing all the data binding yourself.
Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding.
In this case it's the Presenter's job to pass off the Model to the View so that it can bind to it (Like in ASP.NET MVC). The Presenter will also contain logic for gestures like pressing a button, navigation, etc.
- Pro: by leveraging databinding the amount of code is reduced.
- Con: there's less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.
Model-View-Controller
<![if !supportLists]>1. <![endif]>In MVC, the Controller contains the UI business logic for the View.
<![if !supportLists]>2. <![endif]>All action in the View correlates with a call to a Controller along with an action.
<![if !supportLists]>3. <![endif]>In the MVC, Controller is tightly coupled to the View. I.e. Controller is responsible for determining which View is displayed in response to any action including when the application loads. This differs from MVP where actions route through the View to the Presenter. Also in MVC, every action in the View correlates with a call to a Controller along with an action. In the web each action involves a call to a URL on the other side of which there is a Controller who responds. Once that Controller has completed its processing, it will return the correct View. The sequence continues in that manner throughout the life of the application:
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
One other big difference In implementations of MVC with MVP, the View usually will not have any logic in the code behind.
This is contrary to MVP where it is absolutely necessary as if the View always has delegation code to the Presenter.
Another big difference - Unlike view and controller (In MVC), view and presenter (In MVP) are completely decoupled from each other's and communicate to each other's by an interface
Today, this pattern is used by many popular framework like as Ruby on Rails, Spring Framework, Apple iOS Development and ASP.NET MVC.
Presentation Model / Model-View-ViewModel.
One other pattern to look at is the Presentation Model pattern. In this pattern there is no Presenter. Instead the View binds directly to a Presentation Model. The Presentation Model is a Model crafted specifically for the View. This means this Model can expose properties that one would never put on a domain model as it would be a violation of separation-of-concerns. In this case, the Presentation Model binds to the domain model, and may subscribe to events coming from that Model. The View then subscribes to events coming from the Presentation Model and updates itself accordingly. The Presentation Model can expose commands which the view uses for invoking actions. The advantage of this approach is that you can essentially remove the code-behind altogether as the PM completely encapsulates all of the behaviour for the view. This pattern is a very strong candidate for use in WPF applications and is also called Model-View-ViewModel.
Reference:
Hope this helps.
Thanks & Regards,
Arun Manglick,
