The difference between MVC and MVP

What's the difference between MVC and MVP?

As you can see from this picture, we can see that in MVC, view is directly accessible to the model! As a result, the view contains the model information and inevitably includes some business logic.

In the MVC model, more attention is paid to the constant of the model, while there are several different displays of the model, and the view.

So, in the MVC model, models do not depend on view, but view is dependent on model. Not only that, because some business logic is implemented in view, it is difficult to change the view, at least those business logic is not reusable.

Rapid development tools such as Visual Studio make it difficult to separate the view from the controller, and we always complete the controller's code directly in the view's event response function. in ASP. NET and XAML, a technique called code-behind is used to separate the view from the controller. In this way, the view can be done entirely by the UI design engineer, and the controller is done by the programmer, and the two can be synthesized directly without the need to do a lot of work by the programmer as it is now.

What's the problem with mixing the controller with the view?

1. Difficult to test.

You must manually click and use a variety of automated test tools.

2. Code is difficult to reuse.

The UI is difficult to reuse because the requirements are always different. So, the code that causes duplication is everywhere, maintenance hassle.

How does the MVP solve the MVC problem?

In the MVP, presenter completely separates the model from the view, and the main program logic is implemented in presenter. Furthermore, presenter is not directly related to the specific view, but interacts through a well-defined interface, allowing the presenter to be kept constant when the view is changed, that is, reuse!

Not only that, we can also write Test view, simulate the user's various operations, so as to achieve the test of presenter-without the need to use automated testing tools.

We can even test the logic of presenter by writing a mock Object (that is, an interface that implements the model and view, but no concrete content) when the model and view are not finished.

In the MVP, the logic of the application is mainly implemented in presenter, where the view is a very thin layer. As a result, a design pattern for presenter first was proposed, which was to design and develop presenter based on user story. In this process, the view is simple enough to display the information clearly. At the back, you can change the view as you want, without any effect on the presenter.

If the UI to be implemented is complex, and the associated display logic is related to model, you can place a adapter between the view and the presenter. This adapter to access the model and view to avoid the association between the two. At the same time, because the adapter realizes the interface of the view, it can guarantee the same interface with the presenter. This guarantees the simplicity of the interface between the view and the presenter, without losing the flexibility of the UI.

In MVP mode, the view should only have a simple Set/get method, user input and Settings interface display content, in addition to this should not have more content, never allow direct direct access to model--this is a big difference with MVC.

Alex's comparison between MVC and MVP in his blog:

"Translation":

Model View Presenter vs Model View Controller
Brief introduction

In my work, I often have to deal with problems that arise from the fact that developers are not able to clearly understand the differences between MVC and MVP patterns. In this article I will explain some of my understanding of the difference between the two.
It is important to understand that the MVC/P schema is only used for the presentation layer (presentation layer) in an n-tier architecture. These two patterns are not about how to build the data layer and the service layer, but about how to separate the data from the user interface (view) and how the user interface interacts with the data. The use of these patterns allows the presentation layer to be free to change the presentation layer by releasing its dependency on the data and control logic in your program.

A general understanding of the three parts of the two models

1. Model represents the data model and business logic. A model is not always a dataset,datatable thing, it represents a class of components or classes that can provide data externally, and can also fetch data from the outside and store it somewhere. Simple comprehension, you can think of the model as "appearance class (Facade Class)". The appearance here refers to the appearance described in "appearance mode". The general purpose of the appearance is to provide a high-level, easy-to-use access interface for a complex subsystem, which can be understood in the following diagram:

】
2. Views (view) present the data layer to the user. The general view contains only the user interface (UI), not the interface logic. For example, a page that contains controls in ASP. NET is a view. Views can read data from the model, but cannot modify or update the model.
3. The Presenter/controller contains logic to update the model based on the user's behavior in the view. The view simply informs the controller of the user's behavior, and the controller takes the data from the view and sends it to the model.

The core of the mvc/p pattern is to separate the model from the view/controller so that the model is independent of them, so the model does not contain references to views and controls.

What is the MVC (model View Presenter) mode?

1, in order to make the view interface can interact with the model and controller, the controller performs some initialization events
2. The user performs some actions through the view (user interface)
3, the controller handles user behavior (can be implemented by observing the pattern) and notifies the model to update
4. The model raises events to inform the view of changes
5. The view handles the event of the model change and then displays the new model data
6, user interface waiting for further operation of the user

There are a few key points to this model:
1, the view does not use the controller to update the model. The controller is responsible for handling user actions sent from the view and updating the data by interacting with the model
2, the controller can be combined with the view of a piece. This is how the default approach to Windows Forms is handled in Visual studion. For example, we double-click a button, then write the processing logic in its event, and then write the processed data back into the model. The logic time here should be the function of the controller, but instead of writing a controller to do it, we accept the default handling of VS and write it in the form's code, where the form is a view in MVC. So this means that the VS default approach is to combine the controller and the view. 】
3. The controller does not contain the rendering logic for the view (rendering logic)

"Active-MVC" mode, also the MVC pattern in the usual sense

Why do you say you are active? View does not wait for the controller to notify it that the model is updated and then takes the data from the model and updates the display, but instead monitors the model's updates (if in observer mode) or proactively asks if the model is updated. The first way to wait for controller notifications is to implement the "passive-mvc" described below. 】

"Passive-MVC" mode
The difference from active MVC is that:
1. The model is ignorant of the view and controller, it is only used by them
2, the controller uses the view, and notifies it to update the data display
3. The view only does this when the controller notifies it that the model is fetching data (the view does not subscribe to or monitor the update of the model)
4, the controller is responsible for processing model data changes
5. The controller can contain the rendering logic of the view

MVP mode

Very close to the passive-MVC mode, except that the view does not use the model. In MVP mode, views and models are completely detached, and they interact through presenter.
Presenter are very similar to controllers, but they also have some differences:
1, presenter processing view sent over the user action (in MVC, the view has handled these actions)
2, it uses updated data to update the model (in passive MVC, the controller just notifies the view to update the model to fetch new data, while the active MVC model notifies the view to update the display, the controller does not need to work)
3, check the model update (same as passive MVC)
4. (The main difference from MVC) takes data from the model and sends them to the view
5. (The main difference from MVC) informs the view of the updates made
6. (difference from MVC) render view with presenter

The MVP Advantage

1, the model and the view completely separate, we can modify the view without affecting the model
2, you can use the model more efficiently, because so the interaction occurs in a place--presenter internal
3, we can use a presener for multiple views without changing the logic of presenter. This feature is very useful because view changes are always more frequent than models.
4. If we put logic in presenter, then we can test the logic out of the user interface (unit test)

The MVP question.

Because view rendering is placed in presenter, views and persenter interact too frequently.

One more thing you need to understand is that if presenter renders the view too much, it often makes it too close to a particular view. Once the view needs to be changed, the presenter also needs to be changed. For example, the presenter used to render HTML now also needs to be used for rendering PDFs, so the view is likely to need to be changed.

MVP mode According to the interaction between module,view,presenter, can be divided into passive View (regular MVP) and supervising Controller 2 kinds.

Passive View mode:

One of the biggest differences between MVP and MVC is that "the model and the view layer should not communicate (or even two-way communication)." I think this is also the battlefield that the experts who are doing these two aspects of research are arguing with each other now. There must be various benefits and the price to be paid for the benefits. At least presenter in MVP mode should have "absolute power". Without it, model and view are two islands, although each has its own site (fully decoupled), but does not bring any useful value to the enterprise.

So I have a metaphor here to describe the MVP:
Presenter----is a very powerful woman, even "with what posture", it has to tube.
Of course days million worry more will let oneself to do more and more, finally it is facing is the layer of code increasingly complex, and writing is not very convenient, it is bound to even the event of this kind of chicken feather to calculate the skin of the thing to belong to it tube, tired not tired ah. Finally we see the MVP of the view on the real code patronagejob a lot (state-owned workers), it is no wonder that view as long as the corresponding [IVIEW] interface to implement the corresponding properties and some simple method is done, and eventually call [IVIEW] The view instance under the interface is completely given to presenter, which reminds me of the ability to support "custom template engines (which are ultimately controlled by the MVC framework to control the use of the system or custom template engines)" in MVC, and the skin-changing features that people often hang on their mouths, It's really a bit of a point to think about it (on the spiritual level).

Of course, within Microsoft's understanding of the MVP is also different, as described in the following Supervising Controller modeAnd the passiveview you've seen before.


The supervising controller mode is actually very close to the MVC diagram, but also provides the "two-way communication" between the presenter and the view. This approach also has a lot of different opinions, at least for those who support "one-way dependence" of the developers are "dismissive".
Here, although the Passiveview model is somewhat overbearing, but must be to let the model and the view between the real decoupling, for developers to provide the greatest "control of the sense of accomplishment", can say how to control the view how to control, but therefore the problem is the code writing volume and the implementation of complexity and so on.

The difference between MVC and MVP