服务器客户端系统,4.1.2 保持客户端系统与服务器端系统的数据一致性（1）

4.1.2   保持客户端系统与服务器端系统的数据一致性(1)

2.2节中阐述了客户端保持状态的优势，由于客户端程序中的状态往往是服务器端“业务对象”状态的映射，因此，富因特网应用程序中有状态客户端所面临的一个关键的挑战，就是“保持客户端状态与服务器端状态的一致性”。

为什么“保持客户端状态与服务器端状态的一致性”是一个关键挑战呢？从图4-1中我们就可以看出，Flex客户端系统与Java服务器端系统的主要职责不同：

Flex客户端系统职责：主要是满足用户与计算机系统的人机交互，展示客户需要查看的数据，主要负责展现层。

Java服务器端职责：主要是负责业务逻辑相关的行为，考虑性能、扩展性、并发性等多方面的因素。

从Flex客户端系统的职责我们可以知道，用户可能会经常根据需要修改界面，增加数据展示的内容，也就说，用于人机界面的“模型”(model)可能会经常变化，以下是一个常见的场景：

在人事系统中，有一个人员信息查看界面，开始的一段时间，用户要求以数据表格的形式列出人员信息：编号、性别、姓名、生日。随着系统的使用，用户可能要求在显示人员信息的数据表格上增加“所在部门”一列信息，用以显示人员所在部门的“部门名称”。而在服务器端，“人员”对象仅仅持有“部门内码”这样一个属性，并没有定义“部门名称”这个属性。

针对上述的场景，为了便于理解所讨论的内容，用图4-3描述客户端ActionScript代码所编写的人员信息模型：

图4-3所示的EmployeeInfo类主要根据用户对人机界面的需求进行设计，同时兼顾数据传输的性能。

用图4-4描述Java语言开发的“人员”与“部门”业务逻辑对象：

在图4-4中，Employee类表示“人员”业务逻辑对象，Department表示“部门”业务逻辑对象。其中Employee类的getDepartment()方法以“延迟加载”的实现方式获取人员所在的部门对象(Department类型的对象)。

通过对上述场景的分析，我们会得出这样一个结论：相对于客户端“模型”的易变，服务器端的业务逻辑对象则相对稳定。因此，不稳定的客户端模型和相对稳定的业务逻辑模型之间的矛盾是我们在构架中需要解决的一个问题。

同时，从上面场景和类定义中我们还可以看出：定义客户端模型主要考虑的是人机界面需求以及数据传输性能，定义服务器端的业务逻辑对象则主要考虑业务逻辑需求以及业务逻辑的执行性能。因此，Flex客户端模型对象与服务器端业务逻辑对象很难保持一致的属性定义。比如在上面的场景中，客户端要求“人员信息”模型中有“部门名称”属性，即客户端的EmployeeInfo类的DeptName属性，而从图4-4的类定义中我们可以看出，服务器端表示人员的Employee对象中仅仅持有部门内码(deptId)属性和延迟加载其所在部门对象的getDepartment()方法，没有与之对应的DeptName属性。有时候，我们为了提高客户端与服务器之间的数据传输性能，只是把客户端需要的对象属性传送给客户端，而不是把整个对象的所有属性都传送给客户端。比如，为了提高数据传输性能，客户端的EmployeeInfo类仅需要员工所在部门的内码(deptId)和名称(deptName)属性，因此，设计者并没有像服务器端表示人员的Employee类那样，通过getDepartment()方法来获取所在部门(Department)对象，也就是说，不需要把员工所在部门的所有信息都传递到客户端。这也是导致Flex客户端模型对象与服务器端业务逻辑对象难以保持属性定义一致性的一个主要原因。

由此可见，使用Flex+Java所开发的异构分布式Web应用与传统Web开发技术有所不同，上述问题就是我们在使用Flex+Java进行企业应用开发时主要考虑的架构问题。当然，读者可能还会关心其他一些问题。各种论坛上，我们发现很多传统Web开发者比较关注的一个问题就是Session访问。传统的Web开发中，开发者往往会在Session中保存与当前操作者相关的一些状态信息，比如操作者的身份信息等，因此Session访问是Web应用开发中一项非常基本的要求。

那么，当我们使用Flex之后，由Flex客户端发起的请求能否访问Session？如何访问Session？

其实，使用Flex和Session的关系不大，只要选择的通信方式是基于HTTP协议，就能够访问Session，而如何访问Session则取决于通信方式。第5章介绍BlazeDS框架原理时阐述了BlazeDS如何在HTTP协议上完成工作，而在第7章中，则给出BlazeDS框架下访问Session的代码，通过这两章内容读者就能够掌握有关Session的全部问题。而在本节中，我们着重解决前面提到的除了Session之外的，由Flex+Java所开发的这种异构分布式Web应用所带来的问题。

当我们确定Flex+Java所开发Web应用是异构分布式Web应用时，其实，我们就已经找到了答案。在开发异构分布式应用时通常使用两种最简单的设计模式的组合就可以解决以上问题：

远程外观(Remote Facade)模式

数据传输对象(DTO-Data Transfer Object)/值对象(VO-Value Object)模式

Martin Fowler等人在《Patterns of Enterprise Application Architecture》一书中详细地阐述了这两种设计模式的用途，未读过该书的读者可以通过本书内容来了解这两种简单的模式以及如何运用这两种模式组合来解决上面所遇到的问题。

著名《设计模式：可复用面向对象软件的基础》中提道：“为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。”这里的Remote Facade则是客户端系统与服务端系统之间的接口，也就是说，Flex客户端使用RemoteObject对象通过BlazeDS框架调用服务器端的Remote Facade对象中的方法，Remote Facade对象方法则调用“领域层”中“领域对象”或“领域服务对象“的方法完成客户端的请求。

DTO/VO则是专门用于远程方法调用过程中传输数据的载体，DTO是服务器端普通Java对象，它不承担任何业务逻辑；VO是客户端ActionScript对象，同DTO一样，它只承载数据，不含任何业务界面逻辑；DTO与VO一一对应，成对出现，分别表示服务器端与客户端的数据。在客户端与服务器端的通信过程中，客户端RemoteObject以VO对象作为参数进行远程方法调用，经过BlazeDS框架后，客户端VO对象被自动转换为服务器端的DTO对象，并且BlazeDS框架会以DTO对象为参数调用Remote Facade对象的相应方法。同样，被调用的Remote Facade对象方法的返回值也是以DTO形式返回，被BlazeDS框架转换为VO后返回给客户端。

【责任编辑：云霞 TEL：(010)68476606】

点赞 0