移动App架构设计
2015-12-25 15:14
246 查看
移动App架构设计
本文主要总结了几种常用的架构模式, 基本是层层递进的 转载请注名出处 http://blog.csdn.net/uxyheaven, 良好的排版在https://github.com/uxyheaven/NativeAppFrameworkDesign阅读。Native app的开发相比传统的项目迭代周期要短很多, 需求的变化也频繁一些, 在开发的不同生命周期里采用不同的架构模式可以有效的节约开发时间, 提高开发效率, 这篇文章介绍几种常用的架构模式:
表现层的设计
基本的MVC
移动app一般都是采用经典的mvc框架层次 | 作用 | 设计原则 |
---|---|---|
模型层(model) | 封装了应用的一系列数据, 并定义了操作, 处理这些数据的逻辑和计算规则。 | 通过Notification,KVO对控制器进行反馈 |
视图层(view) | 视图对象是一个应用中, 用户可以看到的对象. 视图对象知道如何绘制自己, 也能够响应用户的操作. 视图对象的主要目的之一�是将应用模型对象中的数据显示出来, 并允许用户编辑该数据 | 视图通过不能直接操作模型层, 通过target-action, delegate, dataSource和控制器进行反馈 |
控制器层(controller) | 控制器层是在视图层和若干个模型层的中间人 | c可以直接操作模型层和视图层 |
![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/mvc.png)
总结:
C对M:API
C对V:Outlet
V对C:Target-action, Delegate,Datasource
M对C:Notification,KVO
MVC的改进版
MVVM
MVVM是在MVC的基础上多了一个View Model: 表示逻辑, 将 model 的数据转换为 view 可以呈现的东西. 适合大量展示类的App.![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/mvvm.png)
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处理切换主工作区.
优点:
把程序分成了几个部分, 降低了依赖性
支持鼓励重用代码, 组件或者模块。
在今后的维护中, 提高了可扩展性。
![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/hmvc.png)
分层设计
三层架构
我们在来看一下经典的三层架构从上至下为
表现层(UI)
业务逻辑层或称为领域层(BLL)
数据访问层(DAL)
层次 | 作用 | 设计原则 |
---|---|---|
表现层(UI) | 向用户展现特定业务数据,采集用户的输入信息和操作 | 用户至上,兼顾简洁;不包含任何业务相关的逻辑处理 |
业务逻辑层(BLL) | 从DAL中获取数据, 在UI显示; 从UI中获取用户指令和数据, 执行业务逻辑或通过DAL写入数据源 | 作为U层与D层的桥梁,目的在于展现清晰的函数结构, 只负责数据处理传递, 不涉及SQL语句和ADO.NET |
数据访问层(DAL) | 直接操作数据库,针对数据的增添 删除 修改 查找; 具体为业务逻辑层或表示层提供数据服务。 | 专门操作数据库, 不考虑数据合法性. 数据库错误返回-1, 逻辑错误返回0, 并告知错误原因, 成功返回1 |
![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/mvc_vs_3.png)
然后呢,我们现在的架构则是
![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/3.png)
四层架构
在三层架构的基础上多了业务规则层, 通常的三层是把业务逻辑和业务规则合并为一个层,统称为业务层. 业务规则层的提出,既可以及时处理用户输入的不合法信息, 又可以及时处理数据库错误, 增大了业务逻辑层的结构清晰度, 让业务逻辑人员专心致志做逻辑.从上至下为
表现层
业务规则层
业务逻辑层或称为领域层
数据访问层
层次 | 作用 | 设计原则 |
---|---|---|
业务规则层(ECL) | 对于UI层传下来的参数来说,检查合法性。 | 用户至上,兼顾简洁;不包含任何业务相关的逻辑处理 |
Service层
service层的架构和普通的分层架构的不同是: service层内部有数据, 可以单独运行.![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/service.png)
从上至下为
表现层
服务层(service)
数据访问层
业务逻辑层
层次 | 作用 | 设计原则 |
---|---|---|
表现层 | 显示与用户的互交 | |
服务层 | service层提供表现层的业务逻辑入口,通过定义接口服务的形式,通过接口调用来完成. | |
业务逻辑层 | 1接收服务层传来的DTO, 然后根据业务规则, 对传入的DTO进行加工, 返回加工后的信息 2 需要为每个对象提供业务行为, 并且这些对象之间是独立的 3 业务对象之间的交互流程通过服务层来组织 | |
数据访问层 | 本地数据远程数据的访问接口 |
其他架构
VIPER
viper这里不多说了,请想了解的自行搜索 ![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/viper.png)
平台
todo ![](https://github.com/uxyheaven/NativeAppFrameworkDesign/raw/master/image/platform.png)
相关文章推荐
- IOS开发 3DTouch
- iOS 设置导航栏之二(设置导航栏的颜色、文字的颜色、左边按钮的文字及颜色)
- iOS Quartz 2D绘图用CGContextRef绘制三角形 —— HERO博客
- 我的第一次份实习工作-iOS实习生-第二个月
- android 常见分辨率(mdpi、hdpi 、xhdpi、xxhdpi )及屏幕适配注意事项
- iOS Kernel Exploitation Training (April 2015)
- android——fragment长时间home或者锁屏java.lang.IllegalArgumentException:No view found for id for....
- Xcode7 通过 Single View Application 得到一个 Empty Application 工程
- Android Hybrid开发入门:原生Android与JS的交互
- iOS给label添加下划线
- 微信发送消息中带网页连接
- Android中Service(服务)详解,四大组件之一:Service
- Android APK反编译之源码
- IOS 中关于自定义Cell 上的按钮 开关等点击事件的实现方法(代理)
- android属性动画animator
- RecyclerView 下拉刷新上拉加载(类似PullToRfresh)
- Android 图形 I-Canvas&Drawable
- ios编程之Core Data(一)
- 微信JS SDK Demo
- iOS开发~CocoaPods使用详细说明