[WCF邮件通信系统应用 之 数据同步程序 之 设计内幕 之 三]

数据同步系统分为数据发送端和数据接收端，

在数据发送端，数据的“变化过程”如下：

1，使用ORM框架，从数据源查询出数据到数据实体对象中；

2，数据实体对象经过“消息转换”组件，转换成系统消息对象；

3，将系统消息对象放到邮件消息对象中（可能需要压缩编码等辅助工作）；

4，使用邮件发送组件，将邮件消息对象发送到数据接收端。

在数据接收端，数据的变化过程跟发送端恰恰相反：

1，使用邮件收发组件，将邮件消息对象接收到消息队列；

2，从邮件消息中取出系统消息对象；

3，使用“消息转换”组件，获得数据实体对象；

4，使用ORM组件，将数据实体对象存储到目标数据库中。

4，由数据同步系统到ESB

从上面的应用架构图中我们看到，系统大致分为3部分：

1，数据处理子系统，包括数据源、目标数据库，ORM组件，数据实体对象；

2，消息处理子系统，包括“消息转换”组件，系统消息对象；

3，邮件通信子系统，包括邮件邮件消息对象，邮件收发组件，邮件服务器；

整个系统的3大子系统都是独立的，其核心在于“消息处理”子系统，从应用扩展来看，我们很容易想到以后系统可以扩展为如下结构：

A：业务处理子系统+消息处理子系统+邮件通信子系统；

B：业务处理子系统+消息处理子系统+WCF / FTP子系统；

C：业务处理子系统+消息处理子系统+消息总线

方案C，是不是很像我们常提起的ESB（企业服务总线）吗？我们由一个设计方案，很顺利的扩展出N种新方案，这就是“设计的魔力”，谁说设计没用？

也许，你会觉得我“哗众取宠”，这些设计算啥啊，只是概念而已，项目有需要大伙加加班一样可以很快搞出来，还是看不出设计有啥用。你要是这么说请给本文一个“鸡蛋”，不用给“鲜花”了。

5，数据的“华丽”变身

我们先看看系统中的类关系图，看看数据是怎么变化的：

第1变：由数据表到实体对象

在本系统中，数据不在是单纯的数据，而是对象，对象本身就是封装数据和操作数据的方法的，系统使用PDF.NET数据开发框架将数据映射到了对象中，这样的对象称为“实体对象”，对于我们习惯的“数据表”而言，这是它的第一次变身；

第2变：由实体对象到消息对象

对于单纯的数据处理系统，将数据表映射成实体对象已经足够了，但是我们的设计目标是系统不仅仅只是处理数据的，至少，我们需要有“反馈对象”告诉我们数据的处理结果，“命令对象”告诉我们该怎么样处理其它问题，而这些对象是不能够直接跨越两个局域网的，需要把它放到邮件或者其它地方，来和其它系统完成通信。所以，系统要求有统一的“消息对象”，方便系统内部和系统间交互数据和调用功能、服务。

在这里，所有的其它对象到消息对象的转换都是通过“消息处理”组件完成，其中，实体对象到消息对象的转换使用了PDF.NET数据开发框架内置的转换类，将实体对象序列化成高效的二进制数据。

第3变：由系统消息对象到邮件消息对象

在步骤2中，转换的都是普通的系统消息对象，经过该步骤的转换，系统间已经可以正常交换消息了，但要把它通过邮件发送出去，还得有几个处理过程，编码，加密，压缩，处理成最适合邮件系统处理的消息格式，最后使用邮件收发组件将邮件消息对象发送出去或者将邮件消息接收下来，存入邮件消息队列。

至此，我们由普通的数据，变成了普通消息对象，再到邮件消息对象，完成了我们的“华丽变身”，我们的数据不再是单纯的数据了，它变成了对象，能够适应各种变化的对象。也许这个过程没有那么直接，甚至效率会有一点点影响，但它能够应对各种可能的变化，能够让我们以统一的对象思维模式来考虑问题，现在，你问我这个系统干了什么，我的回答是：

“将对象由一个系统同步到了另外一个系统”，

而不是

“将数据从A库同步到了另外一个局域网中的B库”。

所以，我们的系统应该改一个名字，不是现在的“数据同步系统”，而应该是“对象同步系统”。