Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.
This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.
| Catalogue of Flutter tips | |
|---|---|
| 【Flutter Tips 01】– TextField text is vertically centered | |
| Configure Flutter environment variables | |
| Common errors are recorded |
Preface: In the development, the quality of architecture design has a great relationship with the subsequent development and iteration, good architecture can be changed, bad architecture often can not move, the following is my own architecture design and opinion, if there is any wrong, please advise.
I. Development mode
Currently there are two modes of Flutter development:
1. Unified management mode: Suitable for creating Flutter project to manage multiple terminals (ios, Android, Web, desktop, etc.)
2. Three-terminal separation mode: It is suitable to reference the Flutter module in the original project and integrate the compiled product of the Flutter module into the native (ios, Android, Web, Desktop, etc.) project.
Ii. Overview of the architecture
There are mainly business layer, base layer, Service layer, DB layer, component layer and extension layer
Business layer: If there is a lot of content under each module, the irrelevant content can be divided into small modules and major modules. The major module refines the small class modules. (Purpose: module division is clear, reduce the association before the module, as far as possible low coupling) later business module similar, separate out, to achieve business modular plug-in. Maintain each service separately.
Base layer: Based on the volume of business and the frequency with which the Flutter is used by the project, it is extracted and plug-in. There can be multiple plug-ins (base components, networks, utility classes, etc.), and it is possible that some projects do not require all of the base layers. Reduce associations (network, log, permissions, utility classes, configuration/constants, topics, internationalization…)
Service layer: interface requests are processed after the request. The control layer/view layer are directly used. Service requests are decoupled. The service layer is associated with the business layer, that is, there must be a corresponding business layer
DB layer: SP, SQLite data cache, etc
Component layer: basic components, later plug-in, as far as possible in the project does not apply to the basic system components, the use of secondary encapsulation of the secondary, such as plug-in, import plug-ins, need a lot of replacement. Provide enough optional attributes to accumulate during development
Extension layer: Extension layer, depending on whether the business of the project uses the extended content. Add or delete. Later can be independent module plug-in. Keep coupling as low as possible. Note: Extension layer (each independent module, belonging to the extension in the business)
Iii. Detailed Diagram of architecture:
Finally: Often choose the appropriate, consistent with the long-term expansion of the business iteration. Architecture is meant to be business-friendly, scalable and flexible. It doesn’t have to be methodical.
Make a note of your own tips for improvement next time.