Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Model View Controller is an architectural pattern that facilitates the development of applications that can be developed, tested, and maintained with ease.
The Model View Presenter design pattern replaces the Controller with the Presenter, which manipulates the model while updating the view. The Presenter contains business logic in the MVVM design pattern while the view and the model are isolated.
This article talks about the MVC, MVP and MVVM patterns.
History of the Model-View-Controller
It was in the year 1979 when Trygve Mikkjel Heyerdahl Reenskaug, a computer scientist, invented the MVC design. He sought to devise a method for breaking down a large user application into smaller, more manageable components.
The MVC pattern was originally used in Small Talk programming language. Model-View-Editor was one of the initial names for the pattern, however it was changed to Model-View-Controller. The MVC pattern was widely employed in desktop applications throughout the 1980s and early 1990s. It became widely popular, in late 1990s.
Read: Exploring REST APIs with Spring MVC
Architectural Patterns vs Design Patterns
An architectural pattern is a generic, reusable solution to a recurrent issue in software architecture within a specific context. Architectural patterns address a myriad of challenges in software engineering, such as computer hardware performance restrictions, high availability, and business risk reduction. Some common architectural patterns include model-view-controller pattern, model-view-view-model, client-server pattern, layered pattern, and so forth.
Design patterns are recommended solutions and practices to common problems often encountered in software applications. While an architectural pattern deals with the overall structure f the application, a design pattern is concerned with how a component in the application should be built.
Architectural patterns deal with how the system’s primary components work together, how messages and data flow through the system, and other structural considerations. Architecture patterns use several component types, each of which is often made up of smaller modules.
Read: Leveraging Design Patterns for Productivity
The Model View Controller (MVC) Pattern
The Model View Controller (MVC), an architectural pattern, decouples an application’s presentation and business logic layers. It embodies three components: the model, the view, and the controller. The model represents the application’s data, the view displays data and the controller updates the view when the data changes.
The model has no understanding of the view or the controller. It usually alerts its observers when there is a change.
The primary goal of the MVC pattern is to separate concerns to ease testability. The MVC pattern allows you to segregate the problems while making your application’s code simpler to test and maintain.
The request is routed via the controller in a typical MVC architecture, connecting the model to the relevant view. The MVC pattern is a compound pattern because while the view and controller leverage the strategy design pattern, the view and model are synchronized using the observer design pattern. The view subscribes to model changes. As the view and controller are decoupled, a controller can be used with several views in the MVC pattern.
The benefits of the MVC pattern are:
- Clean separation of concerns
- Makes it easier to test the application’s code
- Accelerated parallel development
- Promotes de-coupling of the application’s layers
- Facilitates Better code organization, extensibility, and reuse
Albeit the advantages, the MVC pattern has certain downsides as well:
- It is quite complex to implement
- It is not a good choice for small applications
Components of the MVC Pattern
The components of the MVC Pattern are as follows.
Model
The model stores data and communicates directly with the database. This is where all data and related logic for the application is stored. It is responsible for defining business rules that govern data handling and how data is modified or processed. The model is not aware of the controller and view and usually notifies its observers of any changes in the model.
View
The view displays the model’s data and is responsible for how the data is represented in the user interface and how the end-users interact with the application. The view is the visual representation of the model’s data shown in grids, tables, charts, diagrams, forms, and other similar elements.
Controller
The controller controls how a user interacts in MVC applications. Controllers process incoming requests and handle user interactions and input. They also execute the appropriate application logic. In other words, the controller receives the input from the user, verifies the input data, and then executes the appropriate business logic that changes the data model’s state.
The Model View Presenter (MVP) Pattern
Like the MVC pattern, there are three components in the MVP pattern as well. These are the model, the view, and the presenter. The presenter replaces the Controller (in MVC) in the MVP design pattern. The MVP pattern allows for easier mocking of the view and more efficient unit testing of applications. In the MVP pattern, the presenter manipulates the model while simultaneously updating the view.
When your application must support multiple user interface technologies, the MVP design pattern is better suited than the MVC pattern. It is also a good choice if your user interface is complicated and requires a lot of user interaction. The MVP design pattern is better suited for automated unit testing of your app’s user interface than the traditional MVC design.
Read: Intro to Software Design Patterns Using Java
Variations of the MVP Design Pattern
The MVP design pattern has two variations:
- Passive View – in this strategy the view is not aware of the model, and it is updated by the presenter.
- Supervising Controller – in this strategy the view interacts directly with the model to bind data to data controls. The presenter updates the model and manipulates the view only if necessary.
The MVP design pattern provides the following benefits:
- Clear separation of concerns
- Modularity
- Easier to test code
The Model View – View Model (MVVM) Pattern
The ModelView-ViewModel (MVVM) design pattern is a variation of Martin Fowler’s Presentation Model Design Paradigm that builds on the popular MVC pattern. The ViewModel helps separate the presentation layer. The presenter contains the business logic in the MVVM design pattern, and the view is isolated from the model.
The view component is aware of the presenter even if the presenter is oblivious of the view. The presenter represents an abstract view of the user interface. A passive view has no understanding of the model. The view is active in the MVVM design pattern and includes actions, events, and data binding information.
It is important to note that in MVVM, the view doesn’t maintain state information; instead, it is synchronized with the ViewModel. In MVVM, the ViewModel isolates the presentation layer and offers methods and commands for managing the state of a view and manipulating the model.
The view and the Viewmodel in the MVVM design pattern communicate using methods, properties, and events. The view and the Viewmodel have bi-directional data binding, or two-way data binding, which guarantees that the Viewmodel’s models and properties are in sync with the view. In applications that need bi-directional data binding, the MVVM design pattern is ideal.
The MVVM design pattern provides the following benefits:
- Better separation of concerns
- Code reuse
- Easier to test and maintain
Summary of Software Development Design Patterns
A good knowledge of the MVC, MVP and MVVM patterns might help you build applications that are extendable, maintainable, and reusable. This article provided a head start into the MVC, MVP and MVVM patterns and their benefits and drawbacks.
