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.
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.
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.
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.
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.
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.
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.
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.
It represents the UI of the application devoid of any Application Logic. It observes the 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.
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