MVC、MVP、MVVM

MVC是Model-View-Controller的缩写（模型-视图-控制器），它将应用程序划分为三个部分：

• Model: 模型（用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法）是程序的主体部分，主要包含业务数据和业务逻辑。在模型层，还会涉及到用户发布的服务，在服务中会根据不同的业务需求，更新业务模型中的数据
• View: 视图（UI界面展示） 程序呈现给用户的部分，是用户和程序交互的接口，用户会根据具体的业务需求，在View视图层输入自己特定的业务数据，并通过界面的事件交互，将对应的输入参数提交给后台控制器进行处理。
• Controller: 控制器（M和V之间的连接器）用来处理用户输入数据，以及更新业务模型的部分。控制器中接收了用户与界面交互时传递过来的数据，并根据数据业务逻辑来执行服务的调用和更新业务模型的数据和状态。
  
  MVC模式的数据关系
  在于实现关注点分离，即应用程序中的数据模型与业务和展示逻辑解耦。
• View 接受用户交互请求
• View 传送指令到 Controller
• Controller 完成业务逻辑后，要求 Model 改变状态；
• Model 将新的数据发送到 View
• View 更新变化数据
  MVC优点：
  对于混乱的软件组织方式有了一个明确的组织方式，通过Control来掌控全局，同时将View展示和Model的变化分离开
• 耦合性低，视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码。
• 重用性高
• 生命周期成本低
• MVC使开发和维护用户接口的技术含量降低
• 可维护性高，分离视图层和业务逻辑层也使得WEB应用更易于维护和修改
• 部署快
  MVC缺点：
  在View和Model之间是直接进行交互的，也就是说View和Model之间是可以相互产生影响的，这样在代码中就必然会导致View和Model之间的耦合
• 不适合小型，中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
• 视图与控制器间过于紧密连接，视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
• 视图对模型数据的低效率访问，依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

MVP（Model-View-Presenter）是MVC的改良模式
Controller/Presenter负责业务逻辑，Model管理数据，View负责显示只不过是将 Controller 改名为 Presenter，同时改变了通信方向，通过Presenter (MVC中的Controller)来进行的。

MVP数据关系

• View 接收用户交互请求
• View 将请求转交给 Presenter
• Presenter 操作Model进行数据更新
• Model通知Presenter数据发生变化
• Presenter 更新View数据
  MVP特点：
• M、V、P之间双向通信
• View 与 Model 不通信，都通过 Presenter传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现
• View非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而Presenter非常厚，所有逻辑都部署在那里。
• Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，这样就可以重用。不仅如此，还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试–从而不需要使用自动化的测试工具。
  在MVP中，View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部
  MVP优点：
  可以是得整个软件分层清晰，降低耦合度，同时也将Activity从既是Control又是View的境地中解脱出来，只需要单一的负责UI即可，降低了Activity的任务
• M与V完全分离，我们可以修改视图而不影响模型；
• 更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
• 一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
• 我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
  MVP缺点：
  需要加入Presenter来作为桥梁协调View和Model，同时也会导致Presenter变得很臃肿，在维护时比较不方便。而且对于每一个Activity，基本上均需要一个对应的Presenter来进行对应
  视图和Presenter的交互会过于频繁，使得他们的联系过于紧密。也就是说，一旦视图变更了，presenter也要变更
  MVVM是Model-View-ViewModel
  分离视图（View）和模型（Model）
  
  数据关系
• View 接收用户交互请求
• View 将请求转交给ViewModel
• ViewModel 操作Model数据更新
• Model更新完数据，通知ViewModel数据发生变化
• ViewModel 更新View数据

MVVM优点：
可以使得数据流的走向更加的清晰明了，同时也简化了开发，数据和视图只需要进行一次绑定即可

• 低耦合，View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
• 独立开发，开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用ExpressionBlend可以很容易设计界面并生成xml代码。
• 可测试，界面向来是比较难于测试的，而现在测试可以针对ViewModel来写。
  MVVM缺点：
  这种架构方式的实现方式比较不完善规范，常见的就是DataBinding框架