Mvc – What are the improvements of MVP over MVC

designdesign-patternsmvcmvp

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?

Best Answer

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.
Related Topic