MV* Architectures

MVC

Model

Responsible for the business logic of the application.

• Persisting application state: communication with the database.
• Data management: data validation, reading, and writing data.

View

The View stands for UI components such as jQuery, HTML, CSS, etc.

• Presenting data to the user.

Controller

Establishes the relationship between the View and the Model.

• It contains the core application logic.
• Gets informed of the user’s response.
• Updates the Model as per the need.

MVP

Model

Responsible for the business logic of the application.

• Persisting application state: communication with the database.
• Data management: data validation, reading, and writing data.

View

The View stands for UI components such as jQuery, HTML, CSS, etc.

• Presenting data to the user.
• Handling user interaction.

Presenter

• Gets the input from the View.
• Processes the data with the help of the Model.
• Passes the results back to the View after the processing is done.

MVVM

Model

Responsible for the business logic of the application.

• Persisting application state: communication with the database.
• Data management: data validation, reading, and writing data.

View

The View stands for UI components such as jQuery, HTML, CSS, etc.

• Presenting data to the user
• Handling user interaction.

ViewModel

Presents functions, methods, and commands to:

• Uphold the View’s state
• Operate the Model
• Activate the events in the View itself

Goal

The aim of these architectures is to separate the responsibilities of visualizing, processing, and data management for UI applications.

Their goals are to increase:

• Modularity
• Flexibility
• Testability
• Maintainability

Comparison

Performance Evaluation

When we are testing the UI performance, MVP turns out to be the one with the highest reliability and lowest hindrance when it comes to rendering frames. Data binding in MVVM creates an additional overload that could drastically affect its performance when performing complex tasks.

Compatibility

When testing the patterns based on their compatibility, MVVM was the best of the lot due to its data binding which had a positive impact. MVP fared better than MVC, which had serious restating issues.

Modifiability

When we talk about design patterns, it is evident that it should be modifiable since that gives us the option of adding new features and strategies into our app.

• Based on these factors, we observed that changes are very few in MVP and MVVM, with MVVM contributing a lot towards maintainability.
• MVC tends to increase the number of changes in the majority of the cases.

References

In MVC, the View doesn’t have reference to the Controller while in MVP, the View has reference to the presenter and in MVVM, the View has reference to the View-Model.

Entry Point

For MVC, the entry point to the application is the Controller whereas, for MVP and MVVM, the entry point is the View.

Single Responsibility Principle

• MVC does not follow the modular and single responsibility principle.
• MVP and MVVM both follow the modular and single responsibility principle.

Unit testing

• Limited support to Unit testing for MVC.
• Easy to carry out Unit testing but a tight bond of View and Presenter can make it slightly difficult for MVP.
• Unit testability is highest in MVVM.

Evax mobile app implementation

After comparing the three architectures, we found that MVP and MVVM are way better than MVC regarding performance and modifiability.
Regarding MVP and MVVM, both are suitable for our application. We then judged that our application is not complex enough in order to add that extra layer of work/difficulty that comes with the implementation of MVVM. For this reason, we chose to use MVP architecture.

Use case 1: Update phone number

Use case 1: Add and delete a child

References

bacancytechnology.com
geekforgeeks.org
levelup.gitconnected.com
medium.com