春鱼·编程观点

技术在进步, 世界在变得美好...

导航

统一、标准、扩展:模块间数据传送实践

[题解]
本文以实践过程说明的模式, 展示了作者近日项目中一个比较实际的应用过程: 如何制定比较常规的, 标准的和容易扩展的模块间数据通讯模式。本文不是关于如何定义标准数据实体的,所以所述问题的根本与架构设计无关。

[问题背景]
我们的开发小组要在基本分层的思想上设计我们的应用。各个模块都需要在一系列相互之间有关系的,数量众多的表中查询数据,并且这个查询需求各个模块都不尽相同。就拿人员资料的检索为例,有的需要按照基本资料检索(姓名,性别,电子邮件,年龄),有的需要按照业务数据检索,(部门或机构成员,参加某项目,参加某会议,获得某奖项),或者工资在500以上。这些检索规则大相径庭。业务模块如何通知底层检索模块检索的方式和方法?而且这些检索规则很可能需要匹配查询,例如有可能需要检索出姓”张“的,并且年龄在40岁以下的,参加过某项目的,参加过某年某会议的,在某部门任某职的,并且工资在500人民币以上的人员。这些规则看起来可能不起眼,但是某些情况下是必须实现的,而且是客户迫切需要的。怎么办?

[解决问题之关键所在]
第一 必须实现从页面到业务逻辑层的逻辑转义。 这似乎不难办到。也不是今天的主题
第二 从业务逻辑层到数据层的检索转义。这里必须注意的是各个检索规则不是必须有的。数据底层必须给业务层一个自由的接口,使可以增加减少查询规则。
第三 从数据层到后端数据库的逻辑转义。数据层必须正确理解提取给业务层的API, 同时必须能够正确向数据库请求数据。

[实现过程]
由于本文标题是实践,也为了节省篇幅和大家的时间,故省却分析过程,直接说明实现方法。

创建查询规则类:
public class QueryCriterion
{}

实际上业务层向数据层提出查询请求的时候, 传递给数据层一个QueryCeriterion集合. 这个集合是一个继承自System.Collections.CollectionBase的类:
public class QueryCriterionCollection: System.Collections.CollectionBase
{}

可以向其中增加删除QueryCriterion, 来表示不同的查询规则.(CollectionBase基类提供基本Add/Remove方法), 另外需要一个公共特性用来表示各个查询规则之间的逻辑关系。是即...又...还是...或....。就是与/或关系。
public LogicControlFlags LogicControl

其中LogicControlFlags是定义的逻辑关系枚举型数据。

每个查询规则类有一个键来表示查询规则的类型。例如,当前查询规则所限制的是姓名,单位,籍贯还是按照参加过的项目,参加的会议,获得的奖项,或者工资水准。

另外查询规则还应该包含一个Value(值),用来表示匹配的内容。注意:查询规则所匹配的内容是大相径庭的。如姓名,单位仅仅是模糊匹配一个串。但是按照人员的业务数据查询的话,比如参加过的项目,则可能会有年度,项目所属方向,项目中的任务为何都有可能需要匹配。而活动的奖项,则会有年度,奖项等级,所属领域种种不同。而良好的扩充性,灵活性又要求不可能无休止的为类型增加特性。这样我们就不得不将每一项查询规则的值都定义为类。当然,姓名或单位仍然是单值。这样一来我们的Value特性就只能是Object类型。

[基本思路]
如果业务逻辑明白的用户的需求, 则创建一个查询规则集合实例。之后根据具体需求向集合中增加查询规则类。由于每个查询规则类的结构都不同,必须创建包含了查询所匹配内容的Value类。之后将集合传送给数据层。

[数据层实现思路]
数据层拿到查询规则集合后, 遍历集合中的各个规则。依据不同的规则键识别不同的规则Value.. 根据值类型不同将有效信息解析出来。并依据逻辑控制标记生成恰当的SQL命令。向数据库查询。获得返回的数据。

[需要注意的问题]
1. 查询的需求变动很大. 很多时候并不是所有查询规则所定义的匹配内容全部有效. 必须注意设置一些缺省值告诉底层不理会这里的数值.
2. 为了调用人员编码方便, 避免写特别多代码创建新类型的实例并赋值. 应该提供尽量多的构建器方法.
3.查询规则键, 必须设计为独立的枚举类型. 以给编码提供遍历.

posted on 2004-04-14 01:18  春鱼  阅读(1517)  评论(0编辑  收藏  举报