GUI架构方法

某个大神写的UI设计模式的综述类文章，笔记如下：

---

MVC

• 分为两层Domain层和Presentation层，前者负责通用数据的CRUD和逻辑，后者负责展示。
• 对象分为两类：域（Domain）数据对象和显示数据对象。域对象与显示完全无关。
• Model是内存的Bean不是SQL中的行。
• 数据绑定时，没有全局控制器协调多个View，而是使用Observer模式，View直接在Model中监听变化，进而更新自己。
• View有对自己事件的响应和Model-View的映射逻辑，Controller只是提供对Model的更改逻辑（响应用户事件），Model本身是纯数据。
• 核心在于展示与数据分开，Observer更新界面。

VisualWorks的Application Model

• 加入了显示对象，该对象是对域对象的包装，并有一些针对显示的逻辑，例如根据域对象值确定控件颜色（getColor（DomainValue））。
• Presentation Model应该是与View框架独立的。
• 有时为了简化设计，Application Model会直接操作View，增加了耦合，减少了代码量。

Martin Fowler的又一篇文章，关于Presentation Model

• Presentation Model包含了View对应的所有域对象数据和View的状态
• 一般情况下，都是使用对于成员变量的Observe而非整个Model
• 即是决定View状态的只是一个变量，也应该有合理的封装和命名，逻辑是完全由Presentation Model控制的
• 难点在于同步的代码位置：放到View里会比较简练，放到Presentation Model里会比较好测试，但是都会有耦合。可以单独写一个Adapter，基本也就是MVP了。

MVP

• Model与MVC相同，View仅仅是展示的控件对象，没有复杂的响应逻辑和显示逻辑，Presenter是View事件的响应类和Model转换的控制类。
• Presenter是窗口级的不是控件级的。
• Presenter的事件响应是由View传递过来的，不是第一响应者。
• 与Application Model相比，MVP的View状态转换来源于两个方面：Model和Presenter逻辑，而不仅仅是对Application Model变化的Observe。

Humble View

• 为了自动化测试的方便，所有测试框架难于接触的对象都应该尽量无动作（Humble）。
• 这就要求Presenter完全控制逻辑，View不进行任何逻辑操作，只是被动接受各种set操作。View不对Model进行Observe。

---

各种方法的进化逻辑

• 原始
  
  • 为了解耦合
  • 数据与展示分开，形成MVC
• MVC
  
  • 为了实现Model和View间的复杂映射逻辑
  • 增加针对View的数据封装，形成Application Model
• Application Model
  
  • 为了增加灵活性，减少代码量
  • 增加了Application Model与控件的耦合，形成了Presenter
• MVP
  
  • 为了强化自动化测试
  • 尽量将View中的展示逻辑放到Presenter中，形成了Humble View
• Humble View

---

数据绑定方法

• Observer
  
  • 优势在于各个View直接无需进行交互，View级的管控清晰
  • 劣势在于不知道Model更新后会发生什么，逻辑可读性不强
• Flow 优劣势与Observer相反

---

In Android

Android中大致使用的是MVP结构。Presenter是Activity、Adapter等主要逻辑代码；View是Layout中的各种控件；Model并没有具体要求，绑定方法也可以使用Observer（自己写）或Flow模式。

---

由RoboBinding引出，Presentation Model貌似就是在说Application Model。