Why MVP/MVC?

There are several good reasons for using these patterns and most projects would benefit from using these and other patterns.

First, is helps to clarify that Model View Presenter (MVP) and Model View Controller (MVC) are two entirely different patterns that solve the same problem .Both patterns have been in use for several years and focus on separating the view (UI) from the model (Business Classes).

Using the MVC pattern developers create controller classes that are responsible for responding to UI events and updating the model according to the action (event) invoked. While using the MVP pattern developers create presenter classes that do basically the same thing; but, also include the use of a .Net interface to talk to the view. The use of this interface is the major differences between the patterns and makes the presenter generally more loosely coupled then a controller. In some advanced scenarios you need to have both presenters and controller. In those cases the classes work together to isolate the view from the model.

Benefits of using either pattern

· Loose coupling – The presenter/controller are an intermediary between the UI code and the model

· Clear separation of concerns/responsibility

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

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

o 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)

· Adaptable to change – I have been in this business for over 12 years and two things have changed more than any other (UI and Data Access). For example in .Net today we have several UI (WinForm, ASP.Net, AJAX, SilverLight, and WPF), and data access (DataSets, DataReaders, XML, LINQ, and Entity Framework) technologies. By using MVP or MVC it is easier to plug in any of these UI or data access technologies and even possible to support more than one at a time.

To recap the MVP and MVC are two separate patterns that address the same problem. Both patterns focus on isolating the UI from the model and these patterns are more adaptable to change then traditional approaches. I hope you found this helpful.