Consider the choice of scenarios when building an iOS stable application architecture, mainly related to engineering structure, data flow idea and code specification

Structural reconstruction of engineering structure, reduction of coupling confusion and large transformation of control requirements

I'm going to use information flow as a top-down, two-tiered structure of the base layer and presentation layer. The base layer is divided into multiple layers, and the presentation layer can be divided into layers. The main idea is to use the bottom layer of the basic layer as components, the business layer as the most lower part of the assembly of large parts, through the process of forming a complete series of products, make a part in accordance with the idea of throwing into the corresponding base layer in the basket, directory structure can also be carried out in accordance with this. The lower part of these two layers, the smaller the parts are, the easier it is to cope with changes in demand, and the idea of consolidating the upper layers is as good as possible. Take this a few of the familiar features of the product to a simple example to illustrate the structure after the construction of the idea, the module is more, some modules do not go deep to the bottom of the analysis:

基础层－ 网络－－ 收发数据－－－单例（持续使用数据）－－－本地（缓存和持续化存储数据对业务的封装输出）－－－单次使用（API接口Model封装输出和业务逻辑封装的ViewModel，将这些做为业务零件）－ 存储－－－ NSUserDefault（对轻量需要存储的添加下一层业务零件封装）－－－ keychain（对安全级别较高需要存储的添加下一层业务零件封装）－－－ 文件存储（对时效需求短的需要存储的添加下一层业务零件封装）－－－ 数据库存储（对数据量大的需要存储的添加下一层业务零件封装，业务层上一层加一层封装CoreData或SQLite方便日后切换数据库用）－ 动画（下层将动画框架输出成各个可以复用的动画功能小零件）－ 视图风格－ 列表控件－－ 上拉加载更多－－ 下拉刷新－－ GuideView－ WebView控件－ AlertView－ iOS系统空间封装－－ 拍照控件－－ 通讯录－ 二维码－ 语音－ 安全－ 支付－ 统计－ 日志展现层－ 首页－－ 订阅－－ 扫描二维码－－ 发布视频－ 列表－－ 时间轴列表－－－ Listview头部封面－－－ 外链情况Cell－－－ 图片Cell－－－ 广告插入Cell－－－ 留言评论－－－ 赞区域－－ 我的列表－－ 订阅列表－－ 文章列表－ 详细页－－ 分享－－ 内容区－－ 评论－ 登录－－ 注册－－ 登录－－ 忘记密码－－ 条款－－ 上传头像－－ 个人信息修改

The upper layers of each module in the base layer can use a similar cocoapod or cathage approach, and the next layer will be used for business encapsulation of its references.

Note here that the lowest level of granularity needed to be dismantled is as good as possible. Reduce lateral dependencies. Things like common can be broken into the corresponding modules of the base layer, such as the configuration file and statistics related to the base layer of statistics, network related to the network, color fonts in the view style, do not pile in a file. or a variety of third-party category also put in the corresponding group, such as Uiview+additions and uicolor+expanded put into the view style of this module, do not specialize in a category put all the category.

Data flow control mode MVC and Mvcs/mvvm/viper selection

In fact, these are the extensions to MVC, but the direction of the expansion is different. Viper the view and the data in the form of the complexity of adding a lot of people are not familiar with the intention to understand its implementation, but the module reuse has reached the optimal, Mvcs is the most simple for MVC optimization is only the data storage is disassembled. MVVM happens to be between Viper and Mvcs, and ViewModel from the Viewcontroller can logically process the data for the view display, and the view has an operation that uses REACTIVECOCOA to pass the signal to ViewModel for processing.

If it is my personal choice I will choose Viper, because it is more consistent with the idea of fine-grained module division. But for the team to develop more people, or the favor of the MVVM of the compromise solution. MVVM follows the previous structure of the application, placing the view and Viewcontroller in the bottom two layers of the presentation layer, placing the ViewModel and model in the bottom layer of the corresponding module on the base layer. The last thing to say is that no matter what kind of choice, as long as the size of the reduction Viewcontroller, will be changed to fat place in the model or view can be, the highest level of moves to learn after the Supreme state is no recruit win there is a recruit, Sometimes do not need to be rigid in a project to all the modules in accordance with the unified thinking of the box to die, such as a module is very simple to use MVC, generally complex with MVVM, if the project itself is very large business can be used Viper to complete the viewcontroller completely split.

You can see the difference in the following chart:

name	Logic and Views	Data
Mvc	View + Viewcontroller	+ Model
MVCS	View + Viewcontroller + Store	+ Model
MVVM	View + Viewcontroller + ViewModel	+ Model
VIPER	View + Viewcontroller + Wireframe + Presenter + Interactor + Data Manager	+ Entity (Model)

Code specification

The most authoritative should be Apple's own official Apple specification, according to this set is certainly not a problem, and should be followed first. The code structure is mainly based on the experience of different teams. Here's a code structure I'm used to

@property ... #pragma mark-life cycle lifecycle, monitoring and destruction like addsubview and notification are placed here #pragma mark-interface interface #  pragma mark-event response#pragma mark-private method if it is Viewcontroller, this place is the key to slimming, and the business and logic functions related to ViewModel. #pragma mark-delegate agent #pragma mark-getters and setters it is recommended that all the property settings, so that the configuration will be more convenient to modify, it does not seem very confusing  

Consider the choice of scenarios when building an iOS stable application architecture, mainly related to engineering structure, data flow idea and code specification