Purpose of architectural design

Through the design to make the program modular, make the module internal high cohesion and low coupling between modules. Improve the efficiency of program development, easy follow-up test, problem location and maintenance. Do not design for design’s sake, architecture for architecture’s sake.

When the code volume of an App is more than 10W, complex operations are needed. A file is over 5,000 lines of code. The need for synchronous coordination between developments requires architectural thinking.Copy the code

MVC(Model View Controller) design architecture

The View accepts the user interaction request, and the View transfers the request to the Controller. The Controller operates the Model to update the data. After the data is updated, the Model notifies the View to update the data. Cons: Bloated activities/fragments as projects grow. Suitable for small projects with few functions, simple business logic and uncomplicated interface.

MVP Design Architecture

Model: Handles data loading and storage (network or local database); View: responsible for interface data display and interaction with users; Presenter: Coordinator, a bridge between model and view, separating model and view.

View receives user interaction requests; View forwards requests to Presenter; Presenter works on Model to update data; Model notifies Presenter of data changes; Presenter Updates View data.

Advantages: Model and View completely separate, modify each other; Model layer encapsulation can greatly reduce the amount of code. A Presenter can be used for multiple views without changing the Presenter’s logic (views change frequently). Easy to test, bed in Presenter out of the user interface to test logic (unit testing);

Cons: As the business logic increases, a page can be very complex, the UI changes a lot, resulting in a large View interface and a bloated Presenter layer of code.

Adaptation scenarios: For large apps with complex business, too many Models, Views and Presenter will cause visual fatigue, which is not conducive to maintenance and management; For small apps with simple business, the development cost becomes high. MVPS are for projects that are neither big nor small.

MVVM design framework

It’s MVP improvement, addressing MVP deficiencies. MVVM abstracts the View’s state and behavior, separating the View UI from the business logic.

  • Model layer (Model): Responsible for retrieving data from various data sources
  • View layer: corresponding to activities and fragments, show users and process user interaction, drive ViewModel to get data from Model;
  • ViewModel layer: Associate Model with View, View obtains data from Model through ViewModel; After data is obtained, it is automatically bound and the result is refreshed to a new interface. The MVVM architecture can be implemented using official LiveData, DataBinding. For example, the DataBinding schema component binds the ViewModel to an XML file, ensuring that the values in the View come from the ViewModel, reducing the coupling between layout and logic.

View receives user interaction requests; The View passes the request to the ViewModel; ViewModel updates Model data; Model notifies ViewModel of data changes after updating data; ViewModel Updates View data.

Low coupling, class reuse, independent development, class testing.

Cons: Bugs are hard to find; Large projects, data binding will lead to high memory overhead; Simple project, MVVM is overdesigned.

Application scenario: For complex pages, the cost of building and maintaining the ViewModel becomes high. Not suitable for simple and overly complex interfaces.

MVC– > MVP– > MVVM

In MVP, the View doesn’t use the Model directly, it uses the Presenter. All interaction happens inside the Presenter. In MVC, the View reads directly from the Model, not the Controller.

The design framework just provides a specification. It doesn’t matter which framework you use. Which is better to establish a uniform specification.