Pasted from <http://msdn.microsoft.com/en-us/library/cc304760.aspx>

View Updates

When the model is updated, the view also has to be updated to reflect the changes. View updates can be handled in several ways. The Model-View-Presenter variants, Passive View and Supervising Controller, specify different approaches to implementing view updates.

In Passive View, the presenter updates the view to reflect changes in the model. The interaction with the model is handled exclusively by the presenter; the view is not aware of changes in the model.

In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required. Examples of complex UI logic might include changing the color of a control or dynamically hiding/showing controls. Figure 1 illustrates the logical view of the Passive View and Supervising Controller variants.

Figure 1

Passive View and Supervising Controller

The decision to use Passive View or Supervising Controller primarily depends on how testable you want your application to be. If testability is a primary concern in your application, Passive View might be more suitable because you can test all the UI logic by testing the presenter. On the other hand, if you prefer code simplicity over full testability, Supervising Controller might be a better option because, for simple UI changes, you do not have to include code in the presenter that updates the view.

When choosing between Passive View and Supervising Controller, consider the following:

• Both variants allow you to increase the testability of your presentation logic.
• Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.
• Supervising Controller typically requires less code than Passive View because the presenter does not perform simple view updates.

For additional information about the Passive View and Supervising Controller patterns, see Glenn Block’s blog.

Pasted from <http://ameleta.spaces.live.com/blog/cns!5F6316345A821420!163.entry>

MVP vs MVC

Model View Presenter vs Model View Controller

Intro

In my work I often deal with the situation when people use MVС/MVP patters without clear understanding the really difference between them. In this article I will try to explain my view on the issue.

It’s important to understand that in n-tier systems MVP/C patterns are responsible for the presentation layer only. It’s not about how you build data or services layers, it’s about separating the data (model) and the user interface(view), telling you how the user interface communicates with data. Using these patterns gives your application independence on changing presentation without depending on data and controlling logic.

Generally:

1.       Model means data & business logic model. It’s not always a DataSet, DataTable or such stuff. It’s kind of components or classes which can provide data and can receive the data to store it somewhere else. To simplify understanding of Model just think about it as “Façade” class.

2.       View represents data for the user. Generally it’s just the UI, and not always UI logic. For example in ASP.NET the page with controls is View.  The View can receive data directly from Model, but View never updates Model.

3.       The Presenter/Controller contains the logic to update Model regarding the user’s actions into the View. View only notifies Controller about user’s actions. Controller extracts data from View and sends it to Model.

The main point of the MVC/P pattern is to split Model from View/Controller to make Model independent from them. So, Model cannot contain the references to the V/C.

What is the MVC (model-view-controller)?

1.       Controller initializes the events of View interface to interact with model and controller.

2.       The user interacts with View (UI).

3.       Controller handles user’s events (can be the “observer” pattern) and asks Model to update.

4.       Model raises events, informing subscribers (View) about changes.

5.       View (UI) (subscribes to model events) handles Model’s evens and shows new Model’s data.

6.       The User Interface waits for the further user actions.

Primary points are:

1.       View does not use Controller to update Model. Controller handles the events from View to manage user’s interaction and data (via interaction with Model)

2.       Controller can be combined with the View. It’s what the Visual Studio do for the Windows Forms by default. The primary point is logical separation of Model from the View.

3.       The Controller do not contains the rendering logic.

The example below illustrates the “Active-MVC” pattern, also known as “the original MVC pattern”.

There is also the “Passive-MVC” pattern.

The differences are that:

-         Model knows nothing about Controller and View, it only used by them both.

-         Controller uses View asking it to render new data.

-         View uses Model to get the data only when Controller ask View about it (no subscription between View and Model).

-         Controller handle Model data changes.

-         Controller may contain the rendering logic for the View.

And now we are close to MVP pattern.

MVP is like an MVC, but View doesn’t use Model.

In the MVP View and Model are utterly separated from each other using the Presenter. Any interaction between View and Model take place in Presenter.

Presenter is like the Controller, but which:

1.       handles the user events from View (in MVC View handles this events);

2.       updates Model using updated data from View (MVC passive just informs View to get/set new data from Model and MVC active takes no role in it, because Model informs View);

3.       examines Model for changes (like the MVC passive);

4.       (the main difference from MVC) gets Model data and stores them into View;

5.       (the main difference from MVC active) notifies View about updates;

6.       (difference from MVC) renders View using the Presenter

So, MVP has following pros:

1.       Model is separated from View and we can change View independently from Model

2.       We using Model more effective, because all interactions are now in one place –in the Presenter(Controller)

3.       We can use one Presenter(Controller) for many Views without changing the Presenter(Controller) logic, it’s can be useful because View changes more often than the Presenter(Controller)

4.       If we are storing View logic in the Presenter(Controller) we can test the logic independent of user interaction (Unit Testing)

But there are cons:

1.       Too many interactions between View and Presenter because rendering View data is in the Presenter;

Also you need to understand that if you render too much data for View you are tied up on the particular View. So if  View needs to be changed you need to update the Presenter either, For example, if you rendered html and need to render the pdf, there is a big possibility that View need to be changed too.

Pasted from <http://blogs.infragistics.com/blogs/tsnyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx>

Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern is the confusion over the differences.

Before we dig into the differences let’s examine how the patterns work and the key benefits to using either one. Both (MVC & MVP) patterns have been use for several years and address a key OO principal namely separation of concerns between the UI and the business layers. There are a number of frameworks is use today that based on these patterns including: JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory, and the recently announced ASP.Net MVC framework.

Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern),

Model View Presenter (MVP) Pattern

The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

Key Benefits

Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern.

Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.

Clear separation of concerns/responsibility

UI (Form or Page) – Responsible for rending UI elements

Presenter/controller – Responsible for reacting to UI events and interacts with the model

Model – Responsible for business behaviors and state management

Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.

Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.

Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)

Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model). The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

Here are the key differences between the patterns:

MVP Pattern

View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.

Easier to unit test because interaction with the view is through an interface

Usually view to presenter map one to one. Complex views may have multi presenters.

MVC Pattern

Controller are based on behaviors and can be shared across views

Can be responsible for determining which view to display (Front Controller Pattern)

Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.