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"
}