In the company's MVP reconstruction, the company is quite large, and the app is quite complicated (in terms of display logic, business transfer is basically driven by user operations, not business logic), so it is a big MVP, and the three terminals are very bloated. Naturally, splitting will be used to solve the problem, while referring to Google's official architecture model.
Model
Model is the data layer, which is split for business data . According to the SOLID idea, the Model is split into two layers:
- Business Models, which carry some data and atomic logic for these data. However, when it comes to persistence (server communication), you need to go through the Repo (see below)
- ModelGroup, which simply combines sub-Models by type, can be seen as a description of which business Models to combine and how to persist (for Gson). The storage is the Map of Class->Object, which exposes an interface to obtain Object through Class. The data obtained from the Repo layer is ModelGroup
View
Here is mainly Passive View (xml), the idea is still split, but to ensure reuse and stability of the Presenter binding:
- Child View, composed of customized View and layout, is a smaller View part than complex Fragment, bound to a single Presenter (the Presenter can be split into smaller parts as needed)
- ViewGroup, implemented by gluing (ViewGroup that places child layouts) and include child layouts. It will become the root View of Activity/Fragment, carrying a complete page
Presenter
Presenter tries to simplify the external interface (only life cycle, separation of concerns) to glue View-Model. This layer is split for display and business . In the future, it can be easily derived to the ViewModel in MVVM.
- The sub-presenter is responsible for the bonding of a sub-layout and a business model. If the layout requires multiple models, it is implemented by multiple sub-presenters (when it evolves into a VM, you need to use clean arch or other solutions to merge the presenter).
- PresenterGroup, which can be Presenter or Activity/Fragment, PresenterGroup holds ModelGroup and ViewGroup, is mainly responsible for converting ModelGroup to Model, and binding child Presenter to the corresponding View
Converter
Added layer to convert the ModelGroup to the Model required by the child Presenter when binding. It can greatly improve the reuse ability of the sub-presenter, and can guarantee the SOLID of the sub-presenter.
Repo
Added layer to isolate persistence/server logic, and wraps the work of Model layer transformation. At the same time, as the core of transferring data, it is convenient to implement global KVO for the same Model.
function table
A depends on B: A knows the existence of B, has a reference to B, new an instance of B, or calls B's custom constructor.
A uses B: A depends on B, and calls B's method or accesses B's field.
| part | duty | rely | use | Remark | single test |
|---|---|---|---|---|---|
| Activity | Fragment scheduling | Fragment | Repo、Model | Using Model should only exist when using Model to increase or decrease Fragment | no |
| Fragment | Binding | Converter、Model、View | Presenter、Repo | Presenter uses only lifecycle methods | no |
| Repo | Access and pass Model | Model | Store | Yes | |
| Store | Access the Model in different ways | Model | Yes | ||
| Converter | Model conversion | Model | Yes | ||
| Model | Data-Oriented Business Logic | Repo | Yes | ||
| View | xml and custom widgets | MVVM will use Presenter/ViewModel | no | ||
| Presenter | Bind View and Model | View、Model | Testable only when output is ViewState |