iOS研发中架构设计与分层,常见架构设计
2016-01-11 17:46
543 查看
结构设计的层次是否越多越好?
我做(开发)架构的几个原则,根据优先次序高低排列:1. (逻辑)拆分越细越好 2. 依赖关细越少越好 3. 交互越少越好 ... 相互矛盾时,如果没有特殊理由,以优先权高者胜出。由此启发,我觉得设计架构应该拆的越细越好。这样做有如下几点好处:
对于大中型软件,层次越多,每一层就更单纯,更容易维护。
团队成员只需了解一小部分业务,就能顺利进行开发。
相对底层的模块,可以更好的重用。
层次分的越多,开发者对抽象的理解就更深入。
iOS说到分层,有几种常见的做法。
按功能分:有MVC,MVVM......
按层次分:有数据层、逻辑层、展现层......
这些分层看起来五花八门,但实质并不冲突。最近读了一篇文章,深受启发,在其模式的基础上修改了一个自己的架构模式,暂且称之为VPBD。废话不多说,线上架构图:
VPBD.png
下面说说各个模块分别干了什么?
ViewController(View):管理View的层次结构、生命周期、一些组合过的View。
ViewModel:负责转换View需要的数据格式。
Presenter:显示View、ViewController的逻辑。
Router(Wireframe):页面跳转逻辑。
Business:核心业务逻辑,复用性很高。
Model:基本数据模型,根据业务来定义。
DataSource:对于数据的抽象,对于Business层而言,不需要知道它是从网络、数据库还是缓存中得到的。
讲模式不能光说不练,所以我决定写一个Demo来实践这一模式。
国庆过来加了3天班,总算写了一个Demo,因为基于目前公司产品的后台,所以代码就不贴了。讲讲思路就好。
最终的版本比上面图中,做了一些妥协,主要是把Presenter和Router拿掉了。因为目前的项目交互都比较简单,而Presenter和Router都是处理交互相关代码的,所以即使写出来代码也很少。下面是结构图:
VVBD.jpg
更详细的结构图:
arch.png
在最早的代码中,ViewController、Business、ViewModel都是写在ViewController里面的,这样迟早是要把ViewController写爆的。为了i面ViewController复杂化,我就把它拆成了3个部分。
ViewController
负责View生命周期的管理、视图跳转、以及用户事件的接收。
Business
负责所有的业务逻辑,它不需要知道View是怎样的。View需要的数据结构会通过ViewModel来定义,所以Business就是处理逻辑,并把最终数据转换成ViewModel,抛给ViewController即可。这个过程中转换成ViewModel比较简单,最核心的是定义业务逻辑。即这个模块是干嘛的。举个例子:
@interface HJShopModule : NSObject @property (nonatomic,strong) HJShopQueryConfig* queryConfig; @property (nonatomic,copy) NSString* currentShopId; - (void)getShopListOnSuccess:(ResponseArray)successBlock onFailure:(ResponseString)failureBlock; - (void)getShopDetailOnSuccess:(ResponseObject)successBlock onFailure:(ResponseString)failureBlock; @end
上面定义的是一个商店模块,就是商店相关的任何逻辑都应该在这里。一个商店模块能干嘛?这需要从需求出发。
需求1:通过筛选得到商店列表
需求2:查看商店详情
根据以上两个需求,我先把筛选条件封装成一个对象(筛选条件多且复杂),然后调用getShopList方法,该方法会筛选条件解析出来,并向后台请求,请求成功再将数据封装好,丢给ViewController。同理,查看商店详情,同样只需要调用一个接口。这里虽然只写了两个,但是真实情况会有很多接口,比如收藏商店、分享商店......业务需求有多少,这里就要加多少。因为写在这里的方法都差不多,所以可读性、维护性都会比较好。
ViewModel
我这里的ViewModel和MVVM中的ViewModel不太一样。我这里的ViewModel其实是Model的延伸。我们定义Model的时候是根据业务来定的。而ViewModel是根据View的展示需求来定的。两者只是结构上的不同,并没有本质差异。假如ViewModel会增加一些类,但是ViewController就不用再做繁琐无聊的数据转换了。
总结
用了这个模式,ViewController得到了很大的简化,但是以后可能还会有复杂化的问题。尤其是当页面的交互逻辑变得复杂的时候。这时候需要把交互再抽象出来,就像最上面的一张图。但目前我觉得这是没有必要的。
相关文章推荐
- html设置自定义的网站图标和被收藏时显示的图标
- 基于Flume的美团日志收集系统(一)架构和设计
- BIND:DNS主从服务器架构和安全控制详解
- java处理高并发高负载类网站的优化方法
- Hbase原理、基本概念、基本架构
- VS2012发布网站详细步骤
- 第14章2节《MonkeyRunner源码剖析》 HierarchyViewer实现原理-HierarchyViewer架构概述 2
- 第14章2节《MonkeyRunner源码剖析》 HierarchyViewer实现原理-HierarchyViewer架构概述 1
- iOS应用架构谈part4-本地持久化方案及动态部署
- 架构师行为准则
- Clean架构
- 最近看了一位牛人介绍的LOL服务器架构,所以就写一篇博客记录一下收获
- 一些前端网站
- 理解RESTFul架构
- 秒杀系统架构分析与实战
- DRBD+Heartbeat+mysql 高可用性负载均衡
- Android的系统架构及组件
- dedecms网站文章标题与简标题的调用问题
- touchweb网站常见问题,手机网站注意问题(一)
- touchweb网站常见问题,手机网站注意问题(二)