iOS开发框架-DDA架构学习总结

数据驱动是一种思想，数据驱动型编程是一种编程范式。基于数据驱动的编程，基于事件的编程，以及近几年业界关注的响应式编程，本质其实都是观察者模型。数据驱动定义了data和acton之间的关系，传统的思惟方式是从action开始，一个action到新的action，不一样的action里面可能会触发data的修改。数据驱动则是反其道而行之，以data的变化为起点，data的变化触发新的action，action改变data以后再触发另外一个action。若是data触发action的逻辑够健壮，编程的时候就只须要更多的去关注data的变化。思考问题的起点不一样，效率和产出也不一样。

Data-Driven-Architecture

 

2.分层架构

咱们将DDA的架构分为三层：

 

这三层每一层都向下依赖，每一层之间经过面相接口编程的方式产生关联。

Application Layer

在CDD的讨论里已经详细的介绍过应用层（Application Layer）的实现方式和数据流向。DDA里应用层的实现差很少，只不过实现语言换成了Swift。这一层主要由咱们熟悉的UIViewController组成，工做职责包括采集用户数据和展现UI。采集数据是指数据从Application Layer流向Service Layer，展现UI是指观察Service Layer流入的数据变化并改变UI。能够假设这样一个业务场景来讲明Application Layer的工做：用户在SettingController里改变本身的用户名。

数据的流出（采集数据）

用户在SettingController的输入框里输入新的用户名，产生newName: String，newName须要传输到Server，收到成功回执以后再改变Controller当中的展现。这个完整的流程当中newName就是咱们所关心的业务数据，在newName流向Service Layer以前咱们可能须要进行校验（名字是否为空或超过了最大长度），这部分的逻辑更贴近界面的工做，且不涉及任何网络和DataBase操做，因此能够放在应用层。若是经过了校验，下一步就是将newName经过请求告诉Server，全部的网络和DataBase操做都发生在Service Layer，因此咱们只须要将newName传输到Service Layer，到这一步就完成了数据的流出。

数据的流入（改变UI）

Application Layer将newName输出到Service Layer以后，接下来只须要做为观察者监控user: UserProfile这个model当中name property的变化。user model是一个viewModel，使用上和MVVM当中的ViewModel概念一致，ViewModel定义在应用层，但会经过事件观察者的方式绑定到Service Layer当中的RawModel。ViewModel负责把RawModel当中的数据转化成View所须要的样式，View在完成UI的配置以后就不须要维护其它的业务逻辑了。

Service Layer

Servicec Layer负责全部的网络请求实现，DataBase操做实现，以及一些公用的系统资源使用接口（好比GPS，相册权限，Push权限等）。对于Application Layer来讲Service Layer就像是一个0ms延迟的Server，全部的服务都经过protocol的方式暴露给Application Layer。Service Layer和Data Access Layer（DAL）使用相同的RawModel定义，RawModel定义在DAL，从sqlite当中读出数据以后就会被立刻转化成RawModel。RawModel不要和View进行直接绑定，经过ViewModel中转能够将数据改变的核心逻辑放在同一的地方管理，调试的时候会颇有用。上面修改用户名的例子传入的newName，在这一层经过ModifyUserNameRequest通知Server。ModifyUserNameRequest成功回调以后将user model的name property修改成最新值。name一修改Application Layer对应的View马上会收到数据改变的事件并展现新的name。Service Layer接下来须要把newName保存到数据库当中，涉及到和sqlite的交互。全部和sqlite直接打交道的工做都是交给Data Access Layer来作。

Data Access Layer（DAL）

DAL层对下负责和数据库直接交互，对上经过protocol的方式提供数据操做的接口给Service Layer。数据库咱们使用sqlite。DAL层不涉及任何具体的业务逻辑，只提供基础的CRUD接口，这样一旦DAL层稳定下来，项目中后期出现业务bug基本就能够省去在DAL层调试。RawModel也定义在DAL，有些项目会在Service Layer和DAL各自定义本身的model，但每多一层model定义，就多了一次转换和维护的逻辑，对于大部分的项目来讲其实没这个必要。DAL除了提供CRUD以外，还须要搭建线程模型，读写要分线程，并且须要同时提供同步异步两套接口。

这样初步进行职责划分后，咱们能够获得一个细一点的层次图。

 

文献： https://github.com/music4kid/Data-Driven-Architecture-Swift