51

I have read for three days about the Model-View-Controller (MVC) and Model-View-Presenter (MVP) patterns. And there is one question that bothers me very much. Why did software designers invent MVP, when there already was an MVC?

What problems did they face, that MVC did not solve (or solved badly), but MVP can solve? Which problems is MVP intended to solve?

I have read a lot of articles about the history and explanation of MVP, or about differences between MVC and MVP, but none had a clear answer to my questions.

In one of the articles that I read, it was said:

Now onto Model View Presenter, which was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces. In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller.

So, I can't understand, but can it actually be in another way, such that GUI components do not handle user input by themselves? And what exactly does "handle by themselves" mean?

Martin Schröder
  • 354
Victor
  • 621

2 Answers2

66

MVC is conceptually elegant:

  • user input is handled by the controller
  • the controller updates the model
  • the model updates the view/user interface
           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

However: The data- and event-flow in MVC is circular. And the view will often contain significant logic (like event handlers for user actions). Together, these properties makes the system difficult to test and hard to maintain.

The MVP architecture replaces the controller with a presenter, which mediates between the view and the model. This linearizes the system:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

This has the following advantages:

  • Logic (like event handlers and user interface state) can be moved from the view to the presenter.

  • The user interface can be unit tested in terms of the presenter, since it describes the user interface state. Inside the unit test, we replace the view with a test driver that makes calls to the presenter.

  • Since the user interface is isolated from the application logic, both can be developed independently.

But there are also some drawbacks to this approach:

  • It requires more effort.
  • The presenter can easily mutate into an unmaintainable “god class”.
  • The application doesn't have a single MVP axis, but multiple axes: one for each screen/window/panel in the user interface. This may either simplify your architecture or horribly overcomplicate it.
amon
  • 135,795
6

In MVP, the Presenter replaces MVC's Controller. The difference between the two is that the Presenter directly manipulates the View. It is designed for UI frameworks that are primarily event driven (like Windows Forms) without heavy support for rich data binding that would lend to the MVVM pattern (like WPF). Otherwise a lot of the logic for managing view state and updating the backing model would lie in the view itself.

Michael Brown
  • 21,822