GUI应用的若干问题和模式

       我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计， 已经有了很多模式， 比如Martin Fowler的blog中有一篇"GUI Architectures“， 里面介绍了Form & Control、MVC、MVP、Passive View、Presentation Model、 Supervising Controller、Event Aggregator， Observer Synchronization等多种模式。模式可以帮助我们建立优雅的架构， 但前提是弄清楚模式的应用场景。这些模式自然不是凭空产生的， 都是为了解决具体的问题. 模式在实现上的差别， 通常都体现了在约束间的不同取舍， 以及问题的差别. 弄清楚GUI应用面临的设计上的问题， 有助于我们正确的挑选设计方案. 下面我们来看一些GUI应用常见的设计问题。

      

       第一个问题就是界面的变化和业务的变化频率不同， 通常是界面变化更频繁， 而我们希望一方的变化不至于影响另一方的逻辑. 对于这个问题， 一个自然的解决方案就是分离界面显示逻辑和后台业务逻辑. MVC和MVP都涉及到了这一点， 它们的共同特点就是把View和应用程序的其它部分分开了. 这是一个关键的分离， 从此之后应用被分为两部分， 抛开它们彼此可以独立的变化不说. 最大的好处是这两部分的问题也可以分而治之。应用程序的其它部分有自己的问题和方案， 不在我们讨论范围内. 我们后面将聚焦在View和相关的显示逻辑方面的问题.

当然这种分离也不是没有代价的， 一个立即的问题就是View如何更新. MVC和MVP把View分出来制造了这个问题， 它们也同时提供了手段解决这个问题。

• MVP中Presenter完成业务逻辑后可以拿到最新的Model， 它可以操控视图， 根据最新的Model来设置视图的各种属性并刷新。

• MVC中Controller在完成业务逻辑操作后更新Model， Model变化时可以发出事件， View订阅Model更新事件来更新自己。

• MVC有各种变体， 一种是Controller直接把Model推给View， View自己从Model中取出感兴趣的数据来刷新自己。

对视图更新的处理是MVC和MVP在实现上的主要区别: MVP中View不需要知道Model， Presenter直接操作View。MVC中View知道Model， 自己根据Model来更新自己的状态。

 

(图片来自: http://msdn.microsoft.com/en-us/library/ff647859.aspx)

跟View相关的另一个常见问题就是可测试性. 即使其它分出去的部分可以独立测试， 但剩下来的View依然Hold住了一部分显示相关的逻辑. 显示逻辑也是逻辑， 也需要测试， 而通常直接测试GUI界面是相对难以测试的. 现有直接测试GUI的测试工具都面临以下问题:

• 测试耗时长， 因为要启动真实的应用

• 测试比较脆弱， 无论是可靠性还是可维护性， 因为界面元素的变化很频繁， 而通过编程来控制界面和用户真实操作经常有细微的差别， 尤其是时序相关的问题

一个思路就是把显示逻辑从View中分离， 让View退化为简单的GUI控件的容器. MVP做出了最初的努力， 而另外两个模式更加强调了这一点: Presentation Model 和Passive View。