您好,欢迎来电子发烧友网! ,新用户?[免费注册]

您的位置:电子发烧友网 > 源码下载 > 通讯/手机编程 >

iOS应用层架构的定义及CDD详解

大小:0.5 MB 人气: 2017-10-12 需要积分:1
 从2010年开始接触iOS开发到现在,折腾过不少App的架构。从MVC到MVVM,VIPER,MVP,以及最新的ReacTIveCocoa都做过实战尝试,还有其他变种,诸如猿题库iOS客户端架构设计,也做过一些学习研究。这些技术概念如果不熟悉,建议每个链接都点开好好研读下,不要对你的大脑太温柔。在开始架构讨论之前,再推荐一些其他非常值得一读的文章:唐巧-被误解的 MVC 和被神化的 MVVM, Casa Taloyum iOS架构系列文章,objc.io架构系列文章。
  1.应用层架构定义
  其实严格来说,MVC和其他类似概念还算不上一个完整的架构。一个颇具规模的App必然会涉及到分层的设计,还有模块化、Hybrid机制、热补丁等等。MVC这种更像是个设计模式,解决的只是App分层设计当中的应用层(Applicaiton Layer)组织方式。对于一些简单App来说,可能应用层一层就完成了整个App的架构,不用担心业务膨胀对后期开发的压力。这里我介绍一种新的应用层架构方式,名之为CDD:Context Driven Design。
  先明确下我们讨论的范畴,什么是一个App的应用层呢?现在不少App都会做一个分层的设计,一般为三层:应用层、Service层、Data Access层。每一层再通过面向接口的方式产生依赖。
  应用层是直接和用户打交道的部分,也就是我们常常用到的UIViewController,负责数据的展示,用户交互的处理,数据的采集等等。
  Service层位于应用层的下面,为应用层提供公共的服务接口,对应用层来说就像是一个Server,不过API调用的延迟为0ms,Service层里放哪些代码做法没有统一的规范,一般来说会包含业务数据的处理,网络接口的调用,公共系统服务API封装(比如GPS定位、相册、权限控制)等等。
  Data Access层顾名思义是负责处理我们App的基础数据,API设计规范一般遵循CRUD。这一层位于Service层的下方,提供数据库交互所需的API。
  这是基础部分,不同的团队具体做法又会有一些差异。比如有些把Data Access层又叫做Model层,有些把网络模块放在Service层,有些则放在Data Access层,有些把部分的业务数据放到Model里面做成胖Model,有些则坚持使用瘦Model,把业务代码放在独立的地方统一管理,等等差异不一而足。除了分层还有一些公共模块的设计,比如数据库、网络、安全、热补丁、Hybrid机制、性能监测模块、日志模块等等如何配合分层设计,这里就不一一展开了。我们今天讨论的重点在应用层。
  首先声明下,这个CDD其实是我很久之前看Android代码脑洞出来的,刚好解决了我之前组织应用层代码的一个痛点。做过Android的朋友应该都知道,在很多类里都可以通过getContext方法获取到一个context,再通过这个context可以获取到其他系统资源。当时我第一次了解完这个context概念的时候,瞬间产生了一个这样的脑洞:
  iOS应用层架构的定义及CDD详解
  我知道这灵光一闪的脑洞有点大,容我慢慢道来。前面提到应用层其实是在管理一堆UIViewController。拿微信做例子(我真的很喜欢拿微信举个栗子),首页4个tab,4个界面,4个controller,每个controller都有很多UI元素,点击又可以进入二级的controller,各controller可以看成一个独立的模块,有些简单,有些复杂。比如聊天界面这个controller就非常非常的复杂。

非常好我支持^.^

(0) 0%

不好我反对

(0) 0%

      发表评论

      用户评论
      评价:好评中评差评

      发表评论,获取积分! 请遵守相关规定!