一个灵活的.NET文件处理系统体系结构——第一部分

很多公司通过文件导入和导出数据作为与他们合作伙伴的交流方式。在Web服务普及的今天，这种方法看起来有点老土和过时，但是总有一些公司使用这种方法交流。

很多情况下，这种系统都是一次性的设计，所以不是很灵活，给系统可维护性和升级性带来了很大困难。在本系列文章中，我们将为大家介绍此类系统高度动态可扩展的基础体系结构。

如果你对C#,消息队列(MSMQ)，扩展标记语言XML及序列化有全面的了解，那么你对本文出现的一些概念将会有更好的理解。如果你对这些知识的某些方面掌握不是很好，你仍可以从本系列中了解到大量信息。不过，在实现本文给出的这些技术时可能会有些困难。

要求

在我们开始介绍体系结构之前，我们需要定义本系统要完成的功能。下面是对本系统的一些要求：

• 必须横向可扩展
• 必须能过加载任何类型的文件（固定长度，定界符，XML等）
• 必须能够将这些文件从一种格式转换成另一种格式（i.e.，unzip/decrypt文件）
• 必须通过可配置文件编排说明解析文件
• 必须通过文件向数据库插入数据
• 必须能过接受新的处理模块而不必要求重新设置或重新编译整个系统
• 必须在文件放入服务器后立即加载文件

这些要求是通用的，根据你的情况可能还要满足更详细的要求。如果在上面的列表中没有发现你需要的，继续向下看本文。这个体系结构的设计是十分灵活的，你可以根据自己的情况加入其它特性。

体系结构

图A展示了我在这篇系列文章提出的体系结构的大体结构：

图 A —图表1

说明：箭头代表信息流，并不一定是物理文件流。

这个图形包含了下列步骤：

• 文件随机进入系统，“监听器”进程探测这些文件。
• 然后监听器进程发送消息（关于消息创建的更多消息在下一篇文章中介绍）给处理队列表示文件已到达。
• 然后消息路由从处理队列接收消息并决定此消息发往何处。
• 在路由逻辑处理和消息目的地决定完成后，消息被前导到目的队列。
• 在消息到达它的目的对列后，具体的任务处理进程将会读取该消息。一个具体任务处理进程与其它的进程是完全独立的，它可以对消息做任何处理。包括利用消息解压上传的文件，解析与此消息相关的文件入数据库或者对文件做某些操作并将消息送回处理队列以进一步处理。