大连协同办公软件开发测试经常出现的问题比较难易发现。无论是可靠性还是可维护性，因为界面元素的变化很频繁，而通过编程来控制界面和用户真实操作经常有细微的差别，尤其是时序相关的问题。

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

      Passive View针对可测试性的方案是把所有的显示逻辑都从View 中移除，View 不再依赖任何Model，只是提供接口，完全被动地由Controller或者Presenter来设置显示所需数据并刷新。

      Presentation Model则封装了Domain Model拥有的数据到View显示所需车辆精准定位软件开发数据之间的映射。View 不再需要与 Domain Model 打交道自己来把业务数据转换成显示需要的数据，只需从Presentation Model 中取数据，映射逻辑都在 Presentation Model 中。而 View 所需数据和Presentation Model 是简单的一一对应关系。

      我们上面讨论的都是大连协同办公软件开发测试经常出现的问题相对简单的 GUI，比如我们其实假定了 View 和 Model 的一一对应，甚至也假定了应用只有一个Vi e w。然而我们还有多视图的情况。多视图带来了以下问题。

• 当Model 变化时如何保持多个视图间的一致性。

• 多个视图间的交互的可控性。

• 事件的循环触发问题。

      Martin Fowler blog 中描述的Flow Synchronization 和 Observer Synchronization 当Model变化时为刷新多个视图提供了两种方式，分别应对不同的情况。

      Flow Synchronization 在 Model 变化后的某些明确定义的时机明确地更新所有受影响的View。它的优点是显式、直观、可控，缺点是很容易造成多个View之间彼此有依赖，不易扩展，因此它适用于视图较少的情况。

      Observer Synchronization则是让多个View 都订阅Model 的更新事件。这是Observer模式在同步方面的应用，具有Observer松耦合的特点。缺点也不意外，它让用户交互的影响变得隐式了，不易于理解应用整体行为和开发时调试等。

      传统上还有一种用于解决大连协同办公软件开发测试经常出现的问题的可控性并让View之间彼此解耦的模式，就是Mediator。当我们在应用Flow Synchronization 时，如果把View 之间的交互都抽取到一个中介者对象里面，每个View都不知道其他View，只知道中介者对象，当有事件发生时，由中介者对象来更新Model和其他View，那么我们可以获得相对清晰的交互和相对松散的耦合。我们来看一下《设计模式》里面对Mediator的描述。

       用一个中介对象来封装一系列对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立改变他们之间的交互。