iOS 项目结构3 – iOS架构设计与分层[转]

结构设计的层次是否越多越好?
多人都会说,凡事不能走极端,走了极端就过犹不及。所以应该分层,但不能过分分层,应该视具体情况来定。这样的话听起来很有道理,却只是一句废话。当我们遇到问题时,还是摸不着头脑!

看看知名的架构师是怎么说的吧!来自蔡学镛

我做(开发)架构的几个原则,根据优先次序高低排列:1. (逻辑)拆分越细越好 2. 依赖关细越少越好 3. 交互越少越好 ... 相互矛盾时,如果没有特殊理由,以优先权高者胜出。

由此启发,我觉得设计架构应该拆的越细越好。这样做有如下几点好处:

对于大中型软件,层次越多,每一层就更单纯,更容易维护。
团队成员只需了解一小部分业务,就能顺利进行开发。
相对底层的模块,可以更好的重用。
层次分的越多,开发者对抽象的理解就更深入。
iOS说到分层,有几种常见的做法。

按功能分:有MVC,MVVM......
按层次分:有数据层、逻辑层、展现层......
这些分层看起来五花八门,但实质并不冲突。最近读了一篇文章,深受启发,在其模式的基础上修改了一个自己的架构模式,暂且称之为VPBD。废话不多说,上架构图:

下面说说各个模块分别干了什么?

  • ViewController(View):管理View的层次结构、生命周期、一些组合过的View。
  • ViewModel:负责转换View需要的数据格式。
  • Presenter:显示View、ViewController的逻辑。
  • Router(Wireframe):页面跳转逻辑。
  • Business:核心业务逻辑,复用性很高。
  • Model:基本数据模型,根据业务来定义。
  • DataSource:对于数据的抽象,对于Business层而言,不需要知道它是从网络、数据库还是缓存中得到的。

讲模式不能光说不练,所以我决定写一个Demo来实践这一模式。

国庆过来加了3天班,总算写了一个Demo,因为基于目前公司产品的后台,所以代码就不贴了。讲讲思路就好。

最终的版本比上面图中,做了一些妥协,主要是把Presenter和Router拿掉了。因为目前的项目交互都比较简单,而Presenter和Router都是处理交互相关代码的,所以即使写出来代码也很少。下面是结构图:


更详细的结构图:

在最早的代码中,ViewController、Business、ViewModel都是写在ViewController里面的,这样迟早是要把ViewController写爆的。为了i面ViewController复杂化,我就把它拆成了3个部分。

ViewController

负责View生命周期的管理、视图跳转、以及用户事件的接收。

Business

负责所有的业务逻辑,它不需要知道View是怎样的。View需要的数据结构会通过ViewModel来定义,所以Business就是处理逻辑,并把最终数据转换成ViewModel,抛给ViewController即可。这个过程中转换成ViewModel比较简单,最核心的是定义业务逻辑。即这个模块是干嘛的。举个例子:

举个例子:

@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得到了很大的简化,但是以后可能还会有复杂化的问题。尤其是当页面的交互逻辑变得复杂的时候。这时候需要把交互再抽象出来,就像最上面的一张图。但目前我觉得这是没有必要的。

关东升:  这与我一直提倡的四层架构(表示层、业务逻辑层、数据持久层和信息系统层)是类似的,而文章中的ViewModel应该属于表示层。

文/iMinjie
原文:http://www.jianshu.com/p/58040a166a10

 


Comments are closed.