移动办公应用——客户端架构

在确定了需求，完成需求说明之后，就要进入开发阶段啦。开发阶段，可以说是最重要的阶段，开发阶段的成败决定项目的成败。在开发过程中，使用恰当的架构可以加快开发速度，提高项目质量。这里主要介绍几种在开发过程中常用的架构。

MVC

MVC全名是Model View Controller，是模型 - 视图 - 控制器的缩写，是一种软件设计规范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

• 模型（Model）
  针对业务模型，构建与数据交互相关的类，封装与数据库以及网络的交互细节。
• 界面（View）
  响应用户操作，展示后台数据。
• 控制器（Controller）
  负责界面与后台的数据格式封装，业务逻辑的处理。

优点

• 架构清晰，易于理解
• 与传统语言的MVC架构没有大的区别，能够快速适应移动应用的开发

缺点

• MVC没有对于移动应用的改进，效率较低
• 在安卓中，拥有Controller职责的Activity要兼顾界面的加载，显得臃肿

MVP

MVP由MVC架构演进而来，与MVC有一定的相似性。MVP引入的目的是解决在MVC中，Activity过于臃肿的问题。

• 模型（Model）
  负责数据的交互
• 视图（View）
  负责数据的展现，用户的交互
• 展示器（Presenter）
  负责业务逻辑的处理
• 视图接口（View Interface）
  需要视图实现的接口，用于与Presenter交互，降低耦合

优点

• 降低耦合，实现了Model和View真正的完全分离，可以修改View而不影响Model
• 模块职责划分明显，层次清晰
• 隐藏数据
• Presenter可以复用
• 利于测试驱动开发
• View可以进行组件化
• 代码灵活性

缺点

• Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难
• 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁
• 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了
• 额外的代码复杂度及学习成本

MVVM

MVVM由MVP改进而来，对MVP的改进就是引入了Data Binding，使得原来Presenter的工作由ViewModel层自动完成，不需要花费额外的功夫。

• 模型（Model）
  负责数据的封装与交互
• 视图（View）
  负责数据的展示，与用户的交互
• ViewModel
  用于绑定模型与视图，实现数据的同步更改

优点

• 数据自动同步，无需添加Presenter
• 实现简单
• 降低耦合

缺点

• 丧失了Presenter的可复用性，通常一个Model只能绑定一个View
• 丧失了Presenter的灵活性

参考文章：

Android App的设计架构：MVC,MVP,MVVM与架构经验谈
Android MVP 详解