Model View Controller - MVC
The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller. Each of these components are built to handle specific development aspects of an application. MVC is one of the most frequently used industry-standard web development framework to create scalable and extensible projects.
Model
The Model component corresponds to all the data-related logic that the user works with. This can represent either the data that is being transferred between the View and Controller components or any other business logic-related data. For example, a Customer object will retrieve the customer information from the database, manipulate it and update it data back to the database or use it to render data.
View
The View component is used for all the UI logic of the application. For example, the Customer view will include all the UI components such as text boxes, dropdowns, etc. that the final user interacts with.
Controller
Controllers act as an interface between Model and View components to process all the business logic and incoming requests, manipulate data using the Model component and interact with the Views to render the final output. For example, the Customer controller will handle all the interactions and inputs from the Customer View and update the database using the Customer Model. The same controller will be used to view the Customer data.
Model View Presenter - MVP
MVP (Model View Presenter) is a design pattern which allows the application developing in gwt to follow MVP architecture. MVP provides the solution of the problem of complexity for developing application. Application development is complex as many developer working on same code due to which all follow same design pattern.
Model
In this segment model consist of data only. It holds within the business object which is to be manipulated and calculated according to application need.
View
It only consists of view i.e. display the data which is given by presenter. It provides reusability of view code as we can swap the new view very easily. It only deals with the HTML and CSS which also helps in separate testing.
Presenter
It contains all the logic which is to be implemented in the application development. It communicates with model as well as view. It is complete distinct in operation which provide separate JUnit testing.
Model View ViewModel - MVVM
MVVM pattern has some similarities with the MVP(Model — View — Presenter) design pattern as the Presenter role is played by the ViewModel. However, the drawbacks of the MVP pattern has been solved by MVVM. It suggests separating the data presentation logic(Views or UI) from the core business logic part of the application.
Model
This holds the data of the application. It cannot directly talk to the View. Generally, it’s recommended to expose the data to the ViewModel through Observables.
View
It represents the UI of the application devoid of any Application Logic. It observes the ViewModel.
ViewModel
It acts as a link between the Model and the View. It’s responsible for transforming the data from the Model. It provides data streams to the View. It also uses hooks or callbacks to update the View. It’ll ask for the data from the Model.
The Difference:
MVC MVP MVVM
Oldest software architecture | Second iteration of software architecture which is advance from MVC | Industry-recognized architecture pattern for applications |
UI and data-access mechanism are tightly coupled. | It resolves the problem of having a dependent View by using Presenter as a communication channel between Model and View. | This architecture pattern is more event-driven as it uses data binding and thus makes easy separation of core business logic from the View. |
Controller and View exist with the one-to-many relationship. One Controller can select a different View based upon required operation. | The one-to-one relationship exists between Presenter and View as one Presenter class manages one View at a time. | Multiple View can be mapped with a single ViewModel and thus, the one-to-many relationship exists between View and ViewModel. |
Difficult to make changes and modify the app features as the code layers are tightly coupled. | Code layers are loosely coupled and thus it is easy to carry out modifications/changes in the application code. | Easy to make changes in the application. However, if data binding logic is too complex, it will be a little harder to debug the application. |
User inputs are handled by controller | View is the entry point to the application | View takes input from the user and acts as entry point of the application. |
Ideal for small business | Ideal for simple and complex applications | Ideal for large projects. Not for small scale projects. |
This architecture has a high dependency on Android APIs. | It has a low dependency on the Android APIs. | Has low or no dependency on the Android APIs. |
The Tech Platform