统一、标准、扩展:模块间数据传送实践
2004-04-14 01:18
232 查看
[题解]
本文以实践过程说明的模式, 展示了作者近日项目中一个比较实际的应用过程: 如何制定比较常规的, 标准的和容易扩展的模块间数据通讯模式。本文不是关于如何定义标准数据实体的,所以所述问题的根本与架构设计无关。
[问题背景]
我们的开发小组要在基本分层的思想上设计我们的应用。各个模块都需要在一系列相互之间有关系的,数量众多的表中查询数据,并且这个查询需求各个模块都不尽相同。就拿人员资料的检索为例,有的需要按照基本资料检索(姓名,性别,电子邮件,年龄),有的需要按照业务数据检索,(部门或机构成员,参加某项目,参加某会议,获得某奖项),或者工资在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.查询规则键, 必须设计为独立的枚举类型. 以给编码提供遍历.
相关文章推荐
- 模块间数据传送实践
- 互联网电商大数据环境 ——大数飓数据分析实践培训精华笔记(六)——电商核心业务知识之订单商品模块
- Delphi编码标准——窗体与数据模块命名
- Dataset用法实践之二 C#数据层模块DLL
- ArcGIS教程:Spatial Analyst 扩展模块栅格数据
- 互联网电商大数据环境 ——大数飓数据分析实践培训精华笔记(七)——电商核心业务知识之订单商品模块
- RBAC权限模型及数据权限扩展的实践
- 互联网电商大数据环境 ——大数飓数据分析实践培训精华笔记(八)——电商核心业务知识之订单商品模块三
- seajs学习日志 简单尝试模板+数据合并、模块异步加载、非标准CMD模式定义define模块
- EBS 各模块数据传送至总帐 需要运行的请求
- IFC标准是为了满足建筑行业的信息交互与共享而产生的统一数据标准,是建 筑行业事实上的数据交换与共享标准。本文概要介绍了IFC标准的产生及发展 历程,IFC的整体框架结构,简要说明了IFC标准的实现方法和过程,描述了 当前的应用以及我们应该更加积极地利用IFC标准为建筑软件行业服务。
- Node.js 使用Stream模块传送数据
- PHP扩展模块解包(由term_to_binary生成的)Erlang ext term格式的二进制数据
- 数据互操作扩展模块介绍一(ArcGIS Data Interoperability)
- EBS 各模块数据传送至总帐 需要运行的请求
- RBAC权限模型及数据权限扩展的实践
- EBS 各模块数据传送至总帐 需要运行的请求
- 标准功能模块组件 -- “文档管理组件,网络文档管理,网络存储”,B/S版本组件可独立运行,也可集成到其他项目里,数据结构清晰思路严谨
- 标准功能模块组件 -- “文档管理组件,网络文档管理,网络存储”,B\S版本组件可独立运行,也可集成到其他项目里,数据结构清晰思路严谨
- 互联网电商大数据环境 ——大数飓数据分析实践培训精华笔记(九)——电商核心业务知识之订单商品模块