声 明
本章节由网友 withwind 和 笔者 共同翻译。
---------------------------------
客户端组件到服务器的通讯
在对客户端组件到服务器的通讯进行设计时，必须应用尽可能小并且细粒度的组件来组建界面，并需要具有包含其他组件的能力，同时还要保留它 * 组件功能的中央控制
* 消息接收的中央控制
* 服务通讯的中央控制
* 分离的代码来控制界面逻辑和事件管理
这个设计在用户界面的基础之上建立了四个类，如下图所示：
图6：客户端组件到服务器通讯所需要的四个类
这四个类各自的职责如下：
* 用户界面是控件（日历，数据表格，检查框，颜色等等）依存的地方。
* 视图逻辑包含操作用户界面的代码，映射数据到字段，描绘数据等等。
* 本地数据模型是指那些为应用程序保存数据的组件。
* 控制器和协调器通常被实现为一个组件。
- 控制器负责为用户界面控制所有的过程。它决定如何处理从远程服务器或从用户界面传来的事件。
- 协调器负责从组件到远程服务的外部通讯。协调器还负责承载那些从远程服务回调的方法。
根据这种方式设计用户界面，无论你以何种形式把组件放在界面中，UI组件们都保持了其个体独立性。通过为个别组件提供一个通用的抽象接口，协调器允许UI组件独立运作或是作为一个更大的界面组件的一部分被使用。下图描绘了客户端结构：
图7：客户端体系结构
以银行应用为例，它包含了一个可以把用户服务请求提交到银行的界面组件。服务中介从界面组件中请求一个针对这个远程服务的处理器使得它可以运行适当的方法。这个界面包括大量的控件以及一个按钮来触发响应事件。界面控制器的视图逻辑能够捕捉到该事件。当事件被调用时，它触发控制器并通知视图逻辑来为本次事务建立本地数据模型。等应用程序将数据模型准备好后，控制器通知协调器，让它提交一个用户服务请求并传递所收集的数据。协调器与服务中介联系，请求适当的服务并传递给它一个针对它自己的操作句柄。当协调器受到从服务中介传递来的消息后，它发出一个消息来产生适当的请求。当服务器上的服务运行结束之后，它传递反应数据消息到客户端。桥接器引导这个反应消息到协调器，以决定调用控制器上的哪个方法，并接着调用那条信息来正确的转变界面外观。
永恒的主题
顺理成章，任何应用程序体系结构都渐渐变得脱离它的独特需求，而开始应该遵循一种严格的设计方法。这篇文章提出两种庞大的客户端模式，你应该把它们所阐述的普遍观点应用在所有应用程序开发项目中。稍后的文章会阐述更多的特殊设计模式和它们所能解决的问题。
向丰富迁移
软件开发，以及促使软件开发逐渐向“技术和问题的集合”方向发展的观点是很总要的。Web程序开发的传统模式把信息和程序资源组织起来，来应对广阔的用户需求，但是往往在可用性和用户体验上面很糟糕。RIA在直觉上保留这种Web部署模式，来响应用户体验。这么一来，这种概念就是围绕着怎样构建重视新功能和用户模式的应用程序展开。在观点上会产生微小变化，运用现有的后端服务器和程序结构，也可提供更好的用户体验。
