In the MVP the UI frontend only interacts with the View and not with the controller. The View is therefore more than just an observer. What this means is that when a user action is received by the page in case of the MVC this is sent to the controller. In case of MVP the user action is sent by the UI page to the view which then in turn calls the presenter. See my diagram below:
Advantages of MVP over MVC
The distinct advantage that MVP has over MVC is that MVP is a better bet for UI intensive projects. MVP is also more accommodating towards mock tests. Some disadvantages of MVP include the time taken to re-factor code to fit this pattern. MVC is better suited for projects with complex navigation. MVP is more suited for winform projects than MVC. Also where applications need to support both winforms and webforms then MVP is the best bet. Because in such cases the Model and the Presenter code can be reused as is.
The MVP is now considered “retired” and is only referred to by its two variants. One a “MVP - Supervising controller” and two a “MVP - Passive View”. The distinction is based on the degree of control a presenter exercises over a view. Advantages in using a Passive View is that it is more testable via mocks. But a supervising controller is more suited than a passive model for heavy UI data that includes grids or lists. Disadvantages of both these types: inclusion of extra levels of layers of code, and a possible lack of awareness of the presenter of changes to the model.
Advantages of MVC over MVP
So where does MVC score over the MVP? MVC takes lesser development time than an MVP. This also takes lesser testing effort than the MVP and suffices for most small medium projects. Also the key to any good design is good controller. So for most projects MVC would suffice.
source: consultingblogs.emc.com
No comments:
Post a Comment