App架构优化

MVC

我记得一开始我开发app的时候是使用MVC架构来进行设计的

对应大家肯定对MVC有所了解

UIView<->Controller层<->Services服务层(网络和一些业务)<->(Models模型层,ApiClient层)

ApiClient层<->框架接口层

而Controllerceng<->功能库/第三方库

–框架接口层主要负责一些底层的功能支持如请求接口,数据存储接口,分享等

– ApiClient层为整个APP网络请求的封装层，提供所有网络请求接口的请求和接受等功能

– Services层为整个APP业务逻辑封装层，比如

实现账号登陆注册业务

– Controller层为View和Services层之间的一层，起到承上启下作用，提供各个模块的UI和业务实现的连接功能

– View层为用户展现UI和用户交互UI层

这种架构随着版本迭代开发出现了越来越多的问题，在开发的后期会由于其超高耦和性，从而造就庞大Controller层，而这也是一直被人所诟病。最终的MVC都从Model-View-Controller走向了Massive-View-Controller的终点，其最严重的结果就是Control层的代码越来越多越来越臃肿难于扩展维护，同时Control层和View层之间存在一些较高的耦合。

MVVM+分层架构设计解耦

UIView<->Controller层<->ViewModel层<->Services服务层(网络和一些业务)<->(Models模型层,ApiClient层)

ApiClient层<->框架接口层

而Controllerceng<->功能库/第三方库

在原有的Controller层和Service层之间插入了一个ViewModel层：

Controller层只用来做中转层不参与业务逻辑等处理

Controller层对上(View层)只提供页面展示所需数据,对下调用(ViewModel层)暴露出的业务逻辑接口

方便进行功能,业务逻辑的单元测试

ViewModel层实现整个业务逻辑,实现对上层只提供接口因此此层灵活,易维护

把Controller层中的 逻辑 抽取出来
这样 Controller层只需要 关注更新UI就行了 其逻辑可以解耦处理
如果逻辑出现问题只需要 去ViewModel中修改对应的部分 不需要改动Controller层

调整前	调整后
Controller层过于复杂	Controller层只用来做中转层不参与业务逻辑等处理
老的Controller层包含了业务逻辑代码使此层的代码量超大并且臃肿不易维护	Controller层对上(View层)只提供页面展示所需数据,对下调用(ViewModel层)暴露出的业务逻辑接口
Controller层包含业务逻辑不能较好,灵活的扩充,分隔等	ViewModel层实现整个业务逻辑,实现对上层只提供接口因此此层灵活,易维护
不能进行功能,业务逻辑的单元测试	方便进行功能,业务逻辑的单元测试

小模块解耦

在上面的的是已经对大模块进行了一次解耦



在左边的图中可以看出 各个小模块间 是没有规律的相互调用 相互依赖相互include的情况导致各个模块相互不能独立,严重影响编译速度和扩展性

关于动态路由组件（DR），是一套可根据规则或下发规则自动实现页面跳转流转的组件，其主要目的为了模块间可以方便容易的横向解耦，拆分，路由，降级容错等初衷。

DR.h
#improt "A.h"
#improt "B.h"

----
A.m
{
#improt "DR.h"
}
----
B.m
{
#improt "DR.h"
}