What are the improvements of MVP over MVC?

Question

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?

Duplicate of http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference — , Dec 14 '16 at 15:43
Yes, I read this post and its answers SEVERAL TIMES, but it is not about my question. There is no answer to my question there. — Victor, Dec 14 '16 at 15:47
I think it's just "The Emperor's New Clothes", a new buzzword from Mickeysoft. — , Dec 14 '16 at 15:52
@ThomasKilian: *[sigh]* There *are* significant differences between the patterns. — Robert Harvey, Dec 14 '16 at 15:54
@RobertHarvey You mean like described in http://mvc.givan.se/papers/MVP_Model-View-Presenter_The_Taligent_Programming_Model_for_C++_and_Java.pdf ? — , Dec 14 '16 at 15:56
@ThomasKilian: I actually wasn't specifically thinking about that paper, no. Though, now that you mention it, the first thing the paper mentions is Smalltalk, and that's part of the problem; the MVC of today is not the same MVC that Smalltalk used. Smalltalk MVC is probably closer to MVP. — Robert Harvey, Dec 14 '16 at 15:57
Yes, Smalltalk was invented the second variation of MVP, the first was invented by Taligent, if I not mistaken. Also in one paper I read, that, " Model View Presenter was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces ". But I do not understand it complete. — Victor, Dec 14 '16 at 16:05
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: https://www.linkedin.com/pulse/understanding-difference-between-mvc-mvp-mvvm-design-rishabh-software — Robert Harvey, Dec 14 '16 at 16:06
But does they solve the same problem? And if so, I think my question is indeed about that, in what different ways? As I understand, MVP was invented with the evolution of GUIs, for meet the needs of modern GUIs, but what needs? How it meet that needs? That is what I want to determine. — Victor, Dec 14 '16 at 16:10
@Victor I've edited the title, hopefully making it briefer and more to the point. If you think it's not right, feel free to edit it again. — Andres F., Dec 14 '16 at 16:25
"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 '16 at 16:33
Oooh, thank you! Unfortunately, it is my nature. I don't stop till I haven't got the answer. :) — Victor, Dec 14 '16 at 16:38
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 '16 at 17:50

score 65 · Answer 1 · answered Dec 14 '16 at 16:15

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.

answered Dec 14 '16 at 16:15

amon

132,749
27
279
375

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 '16 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 '16 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 '16 at 16:43
@RobertHarvey, thank you for the comment. I also meet the explanation of using MVP with client - server architecture, because the MVC not handle that architecture well. That is clear, no questions. But the previous comment's question haunted me! :) – Victor Dec 14 '16 at 16:44
@amon, you lead me closer and closer to the final and complete understanding! One another question, if you not mind. Is there another advantages of MVP against MVC , except that you mention? – Victor Dec 14 '16 at 16:49
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 '16 at 16:58
Oooh, thank you very much, in all cases, you make many things clear! – Victor Dec 14 '16 at 17:18
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 '16 at 00:30

score 6 · Answer 2 · answered Dec 14 '16 at 16:48

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.

What are the improvements of MVP over MVC?

2 Answers2