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

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

      当然这种分离也不是没有代价的，一个立即出现的问题就是 View 如何更新。MVC 和MVP把View分出来制造了这个问题，它们同时也提供了大连OA系统二次开发需要注意的代码架构解决这个问题。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来更新自己的状态。

      跟大连OA系统二次开发需要注意的代码架构相关的另一个常见问题就是可测试性。即使其他分出去的部分可以独立测试，但剩下来的View依然Hold住了一部分显示相关的逻辑。显示逻辑也是逻辑，也需要测试，而通常直接测试 GUI界面是相对难以测试的。现有直接测试 GUI的测试工具都面临以下问题。