对框架设计模式的认识小结

今天阅读了一些设计模式的文章，有一些收获和心得，作如下分享。

首先，说下，这些模式的演变过程（学到源头自然明）

1、自治视图

一个人机交互应用有三个主要关注点，即数据在可视化界面上的呈现、UI处理逻辑（用于处理用户 交互式操作的逻辑）和业务逻辑。自治视图就是把这三种混合在一起，比如早期JSP。这种模式会带来一些问题：

1）丧失了重用性。业务逻辑与UI无关，应该最大限度地被重用，业务逻辑定义在自治视图中，相当于完全与视图本身绑定在一起。

2）业务逻辑稳定，UI处理逻辑次之，而视图调整频繁，业务逻辑和UI逻辑处理和视图绑定在一起，原本不需要改动业务逻辑的部分，因为视图改动而跟着频繁改动。

3）不易测试。

为了解决上述问题，我们需要分离这三着，于是有了MVC模式的出现。

2、MVC模式

附上示意图

Model : 业务功能和数据获取层，接受Controller的请求执行相应的业务功能，并通知给View层

Controller：UI逻辑层，会直接调用Model，更多扮演转化的角色。

View：视图层。

这里顺带说下，三层架构（表现层、业务逻辑层、数据访问层）与MVC模式的区别？

直接附图说明，一目了然

   

3、MVP模式

附上示意图

MVP是一种基于事件驱动的应用框架的模式。MVP不仅仅体现在从Controller到Present的转换，更体现在Model、View和Presenter之间的交互上。能够与Model直接进行交互的仅限于Presenter，View智能间接地通过Presenter调用Model。这样，Model做到了与可视化元素的呈现无关，与UI逻辑处理无关。MVP的应用软件是用户驱动的而非Model驱动的，所以Modele不需要主动通知View以提醒状态发生了改变。

根据View和Presenter之间交互方式以及View本身职责范围，MVP可以分为PV（Passive View）和SoC（Supervising Controller）两种模式。

PV

View经可能不涉及到UI处理逻辑，对UI元素的操作不是有view自身来操作，而是交给Presenter来操控。

SoC

将诸如数据绑定和格式化这样简单的UI处理逻辑转移到View中，在View实现的接口中。尽管View从Presenter接管了部分UI处理逻辑，但是Presenter依然是整个三角关系的驱动者，View被动的地位依然没有改变。

4、MVVM模式

有待后续学习。

参考文章如下：

  MVC、MVP以及Model2[上篇]

    MVC、MVP以及Model2[下篇]

从三层架构到MVC,MVP

Android App整体架构设计的思考(一)

Android App整体架构设计的思考(二)

      android UI设计MVVM设计模式讨论？

Android 开发有哪些新技术出现？