统一、标准、扩展：模块间数据传送实践
[题解]
本文以实践过程说明的模式， 展示了作者近日项目中一个比较实际的应用过程： 如何制定比较常规的, 标准的和容易扩展的模块间数据通讯模式。本文不是关于如何定义标准数据实体的，所以所述问题的根本与架构设计无关。
[问题背景]
我们的开发小组要在基本分层的思想上设计我们的应用。各个模块都需要在一系列相互之间有关系的，数量众多的表中查询数据，并且这个查询需求各个模块都不尽相同。就拿人员资料的检索为例，有的需要按照基本资料检索（姓名，性别，电子邮件，年龄），有的需要按照业务数据检索，（部门或机构成员，参加某项目，参加某会议，获得某奖项），或者工资在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.查询规则键, 必须设计为独立的枚举类型. 以给编码提供遍历.
本文以实践过程说明的模式， 展示了作者近日项目中一个比较实际的应用过程： 如何制定比较常规的, 标准的和容易扩展的模块间数据通讯模式。本文不是关于如何定义标准数据实体的，所以所述问题的根本与架构设计无关。
[问题背景]
我们的开发小组要在基本分层的思想上设计我们的应用。各个模块都需要在一系列相互之间有关系的，数量众多的表中查询数据，并且这个查询需求各个模块都不尽相同。就拿人员资料的检索为例，有的需要按照基本资料检索（姓名，性别，电子邮件，年龄），有的需要按照业务数据检索，（部门或机构成员，参加某项目，参加某会议，获得某奖项），或者工资在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.查询规则键, 必须设计为独立的枚举类型. 以给编码提供遍历.
