移动App架构设计

本文主要总结了几种经常使用的架构模式, 基本是层层递进的转载请注名出处 http://blog.csdn.net/uxyheaven, 良好的排版在https://github.com/uxyheaven/阅读

假设认为本文不错, 请在csdn给个顶, github给个star.

Native app的开发相比传统的项目迭代周期要短非常多, 需求的变化也频繁一些, 在开发的不同生命周期里採用不同的架构模式能够有效的节约开发时间, 提高开发效率, 这篇文章介绍几种经常使用的架构模式:

表现层

主要的MVC

移动app一般都是採用经典的mvc框架

层次	作用	设计原则
模型层(model)	封装了应用的一系列数据, 并定义了操作, 处理这些数据的逻辑和计算规则。	通过Notification,KVO对控制器进行反馈
视图层(view)	视图对象是一个应用中, 用户可以看到的对象. 视图对象知道怎样绘制自己, 也可以响应用户的操作. 视图对象的主要目的之中的一个是将应用模型对象中的数据显示出来, 并同意用户编辑该数据	视图通过不能直接操作模型层, 通过target-action, delegate, dataSource和控制器进行反馈
控制器层(controller)	控制器层是在视图层和若干个模型层的中间人	c能够直接操作模型层和视图层

总结:C对M：APIC对V：OutletV对C：Target-action， Delegate，DatasourceM对C：Notification。KVO

MVC的改进版 MVVM

MVVM是在MVC的基础上多了一个View Model: 表示逻辑, 将 model 的数据转换为 view 能够呈现的东西. 适合大量展示类的App

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdXh5aGVhdmVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

HMVC

Hierarchical MVC, 把client应用程序分解为有层次的父子关系的MVC, 重复应用这个模式, 形成结构化的client架构. 适合重型B/S架构的WebApp.

一个MVC模块由应用程序的一个模块抽象而成. 当中非常重要的一个概念就是 Parent MVC , 它能够相应界面上的实体, 也能够是一个抽象的对象. 设想一个app 有标签栏, 工具栏, 导航栏, 主工作区, 相应到HMVC上就是这个app最底部的标签栏是 Layer1, Layer2 导航栏,主要工作区, 工具栏. 假设认为 Layer2 太复杂能够吧主要工作区放到 Layer3, 依次类推.

Controller 是功能模块的总控室, 它负责和子Controller或父Controller通信，并通知它的 View 处理改变界面显示, Model 处理一些业务逻辑或数据库訪问操作. 如才的样例里, 点击了工具栏里的一个button, 工具栏的Controller 响应这个event, 发现是要切换主工作区, 工具栏做不了,就传递他的父Controller处理(假设父Controller也处理不了, 就继续往上传递)然后标签栏的Controller处理切换主工作区.

长处:

把程序分成了几个部分, 减少了依赖性
支持鼓舞重用代码, 组件或者模块。
在今后的维护中, 提高了可扩展性。

分层设计

三层架构

我们在来看一下经典的三层架构

从上至下为

表示层(UI)
业务逻辑层或称为领域层(BLL)
数据訪问层(DAL)

层次	作用	设计原则
表示层(UI)	向用户展现特定业务数据。採集用户的输入信息和操作	用户至上。兼顾简洁；不包括不论什么业务相关的逻辑处理
业务逻辑层(BLL)	从ＤＡＬ中获取数据, 在ＵＩ显示; 从ＵＩ中获取用户指令和数据, 运行业务逻辑或通过ＤＡＬ写入数据源	作为U层与Ｄ层的桥梁,目的在于展现清晰的函数结构, 仅仅负责数据处理传递, 不涉及ＳＱＬ语句和ＡＤＯ.ＮＥＴ
数据訪问层(DAL)	直接操作数据库，针对数据的增添删除改动查找; 详细为业务逻辑层或表示层提供数据服务。	专门操作数据库, 不考虑数据合法性. 数据库错误返回－1, 逻辑错误返回0, 并告知错误原因, 成功返回1

然后呢,我们如今的架构则是

四层架构

在三层架构的基础上多了业务规则层, 通常的三层是把业务逻辑和业务规则合并为一个层。统称为业务层.业务规则层的提出,既能够及时处理用户输入的不合法信息, 又能够及时处理数据库错误, 增大了业务逻辑层的结构清晰度, 让业务逻辑人员专心致志做逻辑

从上至下为

表示层
业务规则层
业务逻辑层或称为领域层
数据訪问层

层次	作用	设计原则
业务规则层(ECL)	对于UI层传下来的參数来说，检查合法性。	用户至上，兼顾简洁。不包括不论什么业务相关的逻辑处理

引入service层

引入service层的架构和普通的分层架构的不同是: service层内部有数据, 能够单独执行.

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdXh5aGVhdmVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

从上至下为

表现层
服务层(service)
数据訪问层
业务逻辑层

层次	作用	设计原则
表现层	显示与用户的互交
服务层	service层提供表现层的业务逻辑入口,通过定义接口服务的形式,通过接口调用来完毕.
业务逻辑层	1接收服务层传来的DTO, 然后依据业务规则, 对传入的DTO进行加工, 返回加工后的信息 2 须要为每一个对象提供业务行为, 而且这些对象之间是独立的 3 业务对象之间的交互流程通过服务层来组织
数据訪问层	本地数据远程数据的訪问接口

新秀VIPER

viper这里不多说了,请想了解的自行搜索