What is the difference between MVC and MVP?
The MVP is evolved from the classic pattern MVC, where the basic ideas are interlinked: Controller/presenter is responsible for the processing of logic, model provides data, and view is responsible for the display. As a new model,
There is a significant difference between MVP and MVC: in MVP, view does not use model directly, and communication between them is done through presenter (Controller in MVC). All interactions occur inside presenter, whereas in MVC, view reads data from the direct model rather than through a Controller. 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.
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, view should only have a simple Set/get method, the user input and Settings interface display content, in addition to this should not have more content, never allow direct access to model--this is a big difference with MVC.
The advantages of MVP1, the model and the view completely separate, we can modify the view without affecting the model2. Models can be used more efficiently because all interactions occur in one place--presenter internal3, we can use a presenter 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 disadvantage of MVPbecause view rendering is placed in presenter, views and presenter interact too frequently. It is also important to understand that if presenter renders the view too much, it often makes it more closely related 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.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
What is MVP mode?
