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:
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:
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: