50

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?

Improve this question
14
  • 4
    Duplicate of stackoverflow.com/questions/2056/…
    – user188153
    Dec 14, 2016 at 15:43
  • 4
    I think it's just "The Emperor's New Clothes", a new buzzword from Mickeysoft.
    – user188153
    Dec 14, 2016 at 15:52
  • 4
    Victor, do you have a specific question other than "why are there two different patterns?" There are two different patterns because they solve the same problem in two somewhat different ways. If it helps, the Model and the View are essentially the same in both patterns. Focus on the differences between a Controller and a Presenter. You can find more help here: linkedin.com/pulse/…
    – Robert Harvey
    Dec 14, 2016 at 16:06
  • 19
    "I have read for three days about MVC and MVP patterns." Yikes. I suggest you go take a relaxing hot bath or skip some stones across a duck-filled pond or something. That sort of reading can, in the absence of any practical application, really melt your brain!
    – user1172763
    Dec 14, 2016 at 16:33
  • 12
    The way you get the kind of answer you want is by building something using these patterns. Then you will be enlightened.
    – Robert Harvey
    Dec 14, 2016 at 17:50

2 Answers 2

Reset to default
65

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.
Improve this answer
8
  • 7
    Good answer, but modern-day MVC doesn't generally make much (if any) use of event handlers, except perhaps for local form validation, and I don't consider those events part of MVC proper. That's why we have MVP and MVVM. MVC is essentially server-side.
    – Robert Harvey
    Dec 14, 2016 at 16:18
  • @amon, thank you for your answer, it says many things to me. And you mention, that having several axes in application can simplify architecture. I meet that idea in many papers, and there was mentioned, as the one of the main reasons to invent MVP, because MVC not match complex GUIs requirements. That is, which requirements MVP match, and how it solves that requirements? Sorry for being sо persistent, but I REALLY wand to understand it good.
    – Victor
    Dec 14, 2016 at 16:35
  • 5
    @Victor There is no best pattern, but the tradeoffs are different. MVC can be a match for complicated requirements. In terms of architecture, MVP enforces a 1:1 relationship between views and presenters: each view has its own presenter, each presenter is connected to one view. In MVC, there is an n:m relationship: One view can send user input to multiple different controllers, and one controller can receive input from many views. That is more flexible, but also more chaotic – there is no clear “axis” in MVC.
    – amon
    Dec 14, 2016 at 16:43
  • 1
    @Victor I don't have much experience with GUIs, so there's probably a lot that I didn't mention. The last GUI that I did was an absolute mess because I didn't know about MVP at that point – a linearized data & control flow would have been a huge improvement.
    – amon
    Dec 14, 2016 at 16:58
  • 10
    @RobertHarvey I would argue that what the web calls "MVC" was never really "MVC" by the original definition at all. Whoever hijacked the acronym should be hit upside the head for choosing a loaded term and confusing everyone.
    – jpmc26
    Dec 15, 2016 at 0:30
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.