|
Native app的开发相比传统的项目迭代周期要短很多, 需求的变化也频繁一些,
在开发的不同生命周期里采用不同的架构模式可以有效的节约开发时间, 提高开发效率, 这篇文章介绍几种常用的架构模式:
表现层
基本的MVC
移动app一般都是采用经典的mvc框架
总结:C对M：APIC对V：OutletV对C：Target-action，
Delegate，DatasourceM对C：Notification，KVO
MVC的改进版 MVVM
MVVM是在MVC的基础上多了一个View Model: 表示逻辑, 将
model 的数据转换为 view 可以呈现的东西. 适合大量展示类的App
HMVC
Hierarchical MVC, 把客户端应用程序分解为有层次的父子关系的MVC, 反复应用这个模式,
形成结构化的客户端架构. 适合重型B/S架构的WebApp.
一个MVC模块由应用程序的一个模块抽象而成. 其中很重要的一个概念就是 Parent MVC , 它可以对应界面上的实体,
也可以是一个抽象的对象. 设想一个app 有标签栏, 工具栏, 导航栏, 主工作区, 对应到HMVC上就是这个app最底部的标签栏
是 Layer1, Layer2 导航栏,主要工作区, 工具栏. 如果觉得 Layer2 太复杂可以吧主要工作区放到
Layer3, 依次类推.
Controller 是功能模块的总控室, 它负责和子Controller或父Controller通信，并通知它的
View 处理改变界面显示, Model 处理一些业务逻辑或数据库访问操作. 如才的例子里, 点击了工具栏里的一个按钮,
工具栏的Controller 响应这个event, 发现是要切换主工作区, 工具栏做不了,就传递他的父Controller处理(如果父Controller也处理不了,
就继续往上传递)然后标签栏的Controller处理切换主工作区.
优点:
把程序分成了几个部分, 降低了依赖性
支持鼓励重用代码, 组件或者模块。
在今后的维护中, 提高了可扩展性。
分层设计
三层架构
我们在来看一下经典的三层架构
从上至下为
表示层(UI)
业务逻辑层或称为领域层(BLL)
数据访问层(DAL)
然后呢,我们现在的架构则是
四层架构
在三层架构的基础上多了业务规则层, 通常的三层是把业务逻辑和业务规则合并为一个层，统称为业务层.业务规则层的提出,既可以及时处理用户输入的不合法信息,
又可以及时处理数据库错误, 增大了业务逻辑层的结构清晰度, 让业务逻辑人员专心致志做逻辑
从上至下为
表示层
业务规则层
业务逻辑层或称为领域层
数据访问层
五层架构
一般情况下, 我们的业务逻辑放在中间层, 那么对内部的这些大量种类繁多，使用方法也各异的不同的类的调用任务，就完全落到了表示层.
这样势必会增加表示层的代码量, 将表示层的任务复杂化, 和表示层只负责接受用户的输入并返回结果的任务不太相称,
并增加了层与层之间的耦合程度. 因此呢,我们需要增加接口去去统一的管理这些业务, 是设计模式中Facade模式的思想.
从上至下为
表示层
业务外观层
业务规则层
业务逻辑层或称为领域层
数据访问层
引入service层
引入service层的架构和普通的分层架构的不同是: service层内部有数据,
可以单独运行.
从上至下为
表现层
服务层(service)
数据访问层
业务逻辑层
新秀VIPER
viper这里不多说了,请想了解的自行搜索
|
