preface
I just finished the third round of reconstruction of module 20 project, witnessed the advantages and disadvantages of MVC, MVP and Clean and formed my own experience.
Recently, WHILE summarizing work experience, I started to write a blog. And open source the ViaBus architecture I designed.
Common architecture comparison of projects
Below, compare common MVC, MVP, Clean, and AAC architectures.
First, a table shows class redundancy for each schema:
The requirement is to write three pages, namely ListFragment, DetailFragment, and PreviewFragment. Each page uses at least three Note services and three User services. Q: How many classes were written for each of these architectures?
image
Flaws in MVC architecture
View, Controller, and Model depend on each other, resulting in code coupling. It is difficult to divide the View, Controller and Model among different people. Difficult to maintain, with no middleware interface to buffer, and difficult to replace the underlying implementation.
image
Characteristics and limitations of the MVP architecture
The MVP architecture is characterized by interface oriented programming. View, Presenter, and Model are connected by middleware interfaces, and can be seamlessly replaced when a new underlying implementation is available. In addition, MVP’s View and Model do not depend on each other, so it can be said that the View and Model are decoupled from the code.
image
But the MVP structure has its limits. As I understand it, MVP is designed to “make the world free of hard-to-replace Views and models.” The assumption behind the original intention was that “logic at the top is stable, but turnover at the bottom is frequent”. Under the guidance of this assumption, only Presenter has independent will and decision-making power, and controls UI logic and business logic, while View and Model are external tools.
Most of the time, however, such assumptions are unrealistic. Visual requirements are always changing. When it comes to visual interaction, it is necessary to modify the UI logic. In other words, the interaction between View and Presenter makes the UI change need to be completed by the View and Presenter, increasing the cost of communication and collaboration. In the long run, neither will grow. View writers don’t try to be self-reliant, for example by encapsulating the UI into an adaptive component in a polymorphic or other mode. Presenters are all kinds of if and else.
Features and weaknesses of the Clean architecture
image
To address the undefined boundaries of Presenter functions, in the Clean architecture, business logic functions are moved to the domain level, where Usecase manages them full-time. Presenter is reduced to ViewModel, acting as a buffer for proxy data requests and connecting data callbacks.
The Clean architecture is characterized by one-way dependency, data-driven programming. View -> ViewModel -> Usecase -> Model
The View’s one-way dependence on the ViewModel is implemented through the Databinding feature. The ViewModel is only responsible for proxy data requests, and when Usecase returns the result data, the result data is assigned to the observable Databinding data, and the View changes based on that data.
image
But the Clean architecture has a downside: it’s too granular. A Usecase is limited to request parameters and can only handle one class of requests. If the View request contains several types of data, you need to prepare at least a few USecases. Usecase is tailored to the current View’s data needs, so the reuse rate of Usecase is extremely low, and the project will rapidly increase the number of classes and duplicate code.
image
image
AAC architecture features
AAC is also data-driven programming. Instead of relying on the MVVM feature, it writes an observer callback directly into the View to receive the resulting data and process the UI logic.
image
You can think of it as a B/S architecture: a data request is sent from the Web front end to the Web back end, and the back end responds with the resulting data to the front end, which then processes the UI logic as required. In other words, AAC pushes the business completely down to the Model layer.
The origin and characteristics of ViaBus architecture
The last round of refactoring projects was using the Clean architecture, so I decided to skip AAC and write a “message-driven Programming” architecture based on my understanding of mobile data interaction.
It is named ViaBus because the bus is used to broker requests and responses to data.
image
Unlike previous architectures, ViaBus clearly defines what the UI is and what the business is.
The ROLE of the UI is visual interaction, and for that purpose the responsibility of the UI is to request data and process the UI logic. The role of the business is to supply data, so the responsibility of the business is to receive requests, process data, and return result data.
The UI doesn’t need to know how or through whom the data came, it just sends a request to the Bus, and if a business registers a “request handler” of that class, someone else will handle it. The business doesn’t need to know what the UI will do with the data, it just sends the results back to the bus, and if a UI registers a “watch responder,” someone will receive it and act on the response code.
In this way, with the support of static bus, UI and business are completely decoupled, fundamentally solving the problem of mutual involvement. Furthermore, instead of having a Presenter or ViewModel for each View, in ViaBus, the UI in a module can share multiple instances of “business handler”, increasing code reuse to 100%.