Beginner Patterns: MVC vs MVP vs MVVM
Good afternoon, dear colleagues. In this article I would like to talk about my analytical understanding of the differences in the MVC, MVP and MVVM patterns. Write this article I was motivated by the desire to understand the modern approaches in the development of large-scale software and the corresponding architectural features. At the current stage of my career, I am not a direct developer, so the article may contain errors, inaccuracies and misunderstandings. Intrigued, how do analysts see what programmers and architects do? Then welcome under cat.
The first thing I would like to start with is links to external materials that I used as a guide in the process of writing this article:
At a time when the sun was shining brighter and the grass was greener, at that time a team of students, as the author of this article, were developing software by writing hundreds of lines of code directly in the product interface. Sometimes services and managers were used to work with data, and then the solution was obtained using the Document-View pattern. Supporting such a code required enormous costs, since a new developer needs to be trained (to tell) which code is responsible for what in the product, and there was no question of any unit testing. The development team is 4 people who sit in the same room.
Time passed, work changed. Developed applications became larger and more complex, from one cohesive development team there were many different development teams, architects, usabilityists, designers and PMs. Now everyone is responsible for his area: GUI, business logic, components. Appeared department analysis, testing, architecture. The cost of software development has increased hundreds or even thousands of times. Such an approach to development requires a robust architecture that would synchronize different functional areas of the product among themselves.
')
Given the goal of reducing labor costs for the development of complex software, suppose that you need to use ready-made unified solutions. After all, the stereotyped action facilitates communication between developers, allows you to refer to known constructions, reduces the number of errors.
According to Wikipedia , a pattern (an English design pattern) is a repeatable architectural design that represents a solution to a design problem within a framework of some frequently occurring context.
Let's start with the first main thing - Model-View-Controller. MVC is a fundamental pattern that has found application in many technologies, has given development to new technologies and makes life easier for developers every day.
The MVC pattern first appeared in the SmallTalk language. Developers had to come up with an architectural solution that would allow to separate the graphical interface from business logic, and business logic from data. Thus, in the classic version, MVC consists of three parts, which gave it a name. Consider them:
A Model is usually understood as a part containing functional business logic of an application. The model must be completely independent of the remaining parts of the product. The model layer does not need to know anything about the design elements, and how it will be displayed. A result is achieved that allows you to change the presentation of the data, how they are displayed, without touching the Model itself.
The model has the following features:
The duties of the submission include the display of data received from the model However, the view cannot directly affect the model. It can be said that the view has read-only access to the data.
The presentation has the following features:
View examples: HTML page, WPF form, Windows Form.
The most common types of MVC pattern are:
Consider and compare each of them.
This approach allows you to create an abstraction of representation. To do this, you must select the presentation interface with a specific set of properties and methods. The presenter, in turn, receives a link to the interface implementation, subscribes to the presentation events and modifies the model on demand.
Presenter Signs:
Implementation:
Each view must implement an appropriate interface. The presentation interface defines a set of functions and events necessary for user interaction (for example, IView .ShowErrorMessage (string msg)). The presenter should have a link to the implementation of the corresponding interface, which is usually passed in the constructor.
The presentation logic must have a reference to the copy of the presenter. All presentation events are transmitted for processing into a presenter and are almost never processed by the presentation logic (including the creation of other presentations).
Usage example: Windows Forms.
This approach allows you to associate view elements with properties and events of the View model. It can be argued that each layer of this pattern is not aware of the existence of another layer.
Signs of the View Model:
Implementation:
When using this pattern, the view does not implement the corresponding interface (IView).
The view must have a link to the data source (DataContex), which in this case is the View model. View elements are linked (Bind) with the corresponding properties and events of the View model.
In turn, the View-model implements a special interface that is used to automatically update the elements of the view. An example of such an interface in WPF is INotifyPropertyChanged.
Usage example: WPF
The main idea of ​​this pattern is that both the controller and the view depend on the model, but the model does not depend on these two components.
Signs of the controller
Implementation:
The controller intercepts the event from the outside and in accordance with the logic embedded in it, reacts to this event by changing the Model by calling the appropriate method. After a change, the Model uses the event that it has changed, and all Subscriptions subscribed to it, upon receiving it, turn to the Model for updated data, after which they are displayed.
Usage example: MVC ASP.NET
The implementation of MVVM and MVP patterns, at first glance, looks quite simple and similar. However, for MVVM, the view is linked to the View model automatically, and for MVP, it is necessary to program
MVC seems to have more control over presentation.
In conclusion, the author of this article would like to note that strictly adhering to only one pattern is not always the best choice. For example, imagine that you would like to use MVVM to develop applications using Windows Forms through the Bindings control property. Your goal is to separate the presentation from the business of logic and the logic that connects them. The application should be easily tested and supported, and for analysts - understandable (after all, the question “what the hard disk drive is measured in” is the only correct answer - in Joules (an abstract example of the Model -> Views)).
Thank you very much for your time, pleasant reading!
Links
The first thing I would like to start with is links to external materials that I used as a guide in the process of writing this article:
- ru.wikipedia.org/wiki/Model-View-Controller
- ru.wikipedia.org/wiki/Model-View-Presenter
- ru.wikipedia.org/wiki/MVVM
- outcoldman.com/en/blog/show/184
- rsdn.ru/article/patterns/ModelViewPresenter.xml
Introduction
At a time when the sun was shining brighter and the grass was greener, at that time a team of students, as the author of this article, were developing software by writing hundreds of lines of code directly in the product interface. Sometimes services and managers were used to work with data, and then the solution was obtained using the Document-View pattern. Supporting such a code required enormous costs, since a new developer needs to be trained (to tell) which code is responsible for what in the product, and there was no question of any unit testing. The development team is 4 people who sit in the same room.
Time passed, work changed. Developed applications became larger and more complex, from one cohesive development team there were many different development teams, architects, usabilityists, designers and PMs. Now everyone is responsible for his area: GUI, business logic, components. Appeared department analysis, testing, architecture. The cost of software development has increased hundreds or even thousands of times. Such an approach to development requires a robust architecture that would synchronize different functional areas of the product among themselves.
')
Patterns
Given the goal of reducing labor costs for the development of complex software, suppose that you need to use ready-made unified solutions. After all, the stereotyped action facilitates communication between developers, allows you to refer to known constructions, reduces the number of errors.
According to Wikipedia , a pattern (an English design pattern) is a repeatable architectural design that represents a solution to a design problem within a framework of some frequently occurring context.
Let's start with the first main thing - Model-View-Controller. MVC is a fundamental pattern that has found application in many technologies, has given development to new technologies and makes life easier for developers every day.
The MVC pattern first appeared in the SmallTalk language. Developers had to come up with an architectural solution that would allow to separate the graphical interface from business logic, and business logic from data. Thus, in the classic version, MVC consists of three parts, which gave it a name. Consider them:
Model
A Model is usually understood as a part containing functional business logic of an application. The model must be completely independent of the remaining parts of the product. The model layer does not need to know anything about the design elements, and how it will be displayed. A result is achieved that allows you to change the presentation of the data, how they are displayed, without touching the Model itself.
The model has the following features:
- The model is the business logic of the application;
- The model has knowledge of itself and does not know about controllers and views;
- For some projects, the model is just a data layer (DAO, database, XML file);
- For other projects, the model is a database manager, a set of objects, or just application logic;
View
The duties of the submission include the display of data received from the model However, the view cannot directly affect the model. It can be said that the view has read-only access to the data.
The presentation has the following features:
- The view implements the display of data that is obtained from the model in any way;
- In some cases, the view may have code that implements some business logic.
View examples: HTML page, WPF form, Windows Form.
Differences MVP & MVVM & MVP
The most common types of MVC pattern are:
- Model-View-Controller
- Model-View-Presenter
- Model-View-View Model
Consider and compare each of them.
Model-View-Presenter
This approach allows you to create an abstraction of representation. To do this, you must select the presentation interface with a specific set of properties and methods. The presenter, in turn, receives a link to the interface implementation, subscribes to the presentation events and modifies the model on demand.
Presenter Signs:
- Two-way communication with the presentation;
- The presentation interacts directly with the presenter, by calling the appropriate functions or events of the presenter instance;
- Presenter interacts with View by using a special interface implemented by the view;
- One copy of the presenter is associated with one display.
Implementation:
Each view must implement an appropriate interface. The presentation interface defines a set of functions and events necessary for user interaction (for example, IView .ShowErrorMessage (string msg)). The presenter should have a link to the implementation of the corresponding interface, which is usually passed in the constructor.
The presentation logic must have a reference to the copy of the presenter. All presentation events are transmitted for processing into a presenter and are almost never processed by the presentation logic (including the creation of other presentations).
Usage example: Windows Forms.
Model-View-View Model
This approach allows you to associate view elements with properties and events of the View model. It can be argued that each layer of this pattern is not aware of the existence of another layer.
Signs of the View Model:
- Two-way communication with the presentation;
- The view model is an abstraction of the view. Usually means that the properties of the view coincide with the properties of the View-model / model
- The view model has no reference to the view interface (IView). Changing the state of the View-model automatically changes the view and vice versa, because the data binding mechanism (Bindings) is used
- One instance of the View model is associated with a single display.
Implementation:
When using this pattern, the view does not implement the corresponding interface (IView).
The view must have a link to the data source (DataContex), which in this case is the View model. View elements are linked (Bind) with the corresponding properties and events of the View model.
In turn, the View-model implements a special interface that is used to automatically update the elements of the view. An example of such an interface in WPF is INotifyPropertyChanged.
Usage example: WPF
Model-View-Controller
The main idea of ​​this pattern is that both the controller and the view depend on the model, but the model does not depend on these two components.
Signs of the controller
- The controller determines which view should be displayed at the moment;
- View events can only affect the controller. The controller can affect the model and define a different view.
- Perhaps several views for only one controller;
Implementation:
The controller intercepts the event from the outside and in accordance with the logic embedded in it, reacts to this event by changing the Model by calling the appropriate method. After a change, the Model uses the event that it has changed, and all Subscriptions subscribed to it, upon receiving it, turn to the Model for updated data, after which they are displayed.
Usage example: MVC ASP.NET
Summary
The implementation of MVVM and MVP patterns, at first glance, looks quite simple and similar. However, for MVVM, the view is linked to the View model automatically, and for MVP, it is necessary to program
MVC seems to have more control over presentation.
General rules for choosing a pattern
MVVM
- Used in situations where data binding is possible without the need to enter special presentation interfaces (i.e. there is no need to implement IView);
- A frequent example is the WPF technology.
MVP
- Used in situations where data binding is not possible (Binding cannot be used);
- A common example would be the use of Windows Forms.
MVC
- Used in situations where communication between the view and other parts of the application is not possible (and you cannot use MVVM or MVP);
- A common use case is ASP.NET MVC.
Conclusion
In conclusion, the author of this article would like to note that strictly adhering to only one pattern is not always the best choice. For example, imagine that you would like to use MVVM to develop applications using Windows Forms through the Bindings control property. Your goal is to separate the presentation from the business of logic and the logic that connects them. The application should be easily tested and supported, and for analysts - understandable (after all, the question “what the hard disk drive is measured in” is the only correct answer - in Joules (an abstract example of the Model -> Views)).
Thank you very much for your time, pleasant reading!
Source: https://habr.com/ru/post/215605/
All Articles