[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
2010-06-28 06:44
375 查看
.NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
前言:这个系列有段时间没有动了。主要是针对大家的反馈在修改代码。在修改的过程中,也有了一些新的体会,这里和大家分享一下,同时也发布一下业务框架的第一个版本。在本篇文章中,学习到的不是仅仅只是代码,而是设计的思想和实现这种思想的方法。在写本篇时有个感触:把一个东西彻底的讲清楚,不容易。希望大家
多提意见。而且在写本篇的时候,我个人也是很兴奋的,至于原因相信大家在看完之后就知道了。J
本篇的议题如下:
1. 打通业务层和数据层
2. 打通方法的选择和实现
3. 再次借鉴.NET Framework设计思想
4. 水到渠成
5. 代码的版本说明
系列文章链接:
1. 打通业务层和数据层
首先,回顾之前的文章一直讨论的问题:
1. 如何使得数据层”以不变应万变”。
2. 条件对象如何实现
3. 如何在业务层和数据层之间mapping数据
本篇就告诉大家,如何切切实实的解决上面三个问题。
首先,从一个图示开始讲述。
代码
public List<User> GetUserByAge()
{
ICriteria<User> conditionPerson =
CriteriaFactory.Create<User>().Where(u => u.Age < this.Age).OrderBy<string>(u => u.Name).Skip(8).Take(8);
return DataPortal.Query(conditionPerson);
}
上面的代码中,Create方法就是实例化一个ICriteria<User>,此时我们想做的仅仅只是一件事:把在 ICriteria<User>上的操作记录下来而已。然后把记录下来的结果解析,解析的最终结果就是一条sql命令,然后再给不同的DataProvider去执行。也就是说,在DataPortal内部可以配置用什么方法来执行数据操作:是直接使用ADO.NET执行sql命令,还是把sql命令给Entity Framework...通过配置决定。如果ICriteria<T>是从IQueryable接口进行了继承,那么在ICriteria实现这个结果的过程中就必须要去数据库中进行执行,因为Execute方法返回的是T的集合,而不是sql命令(字符串)。
大家可能想到:那就在Execute方法中去实现不同的DataProvider,例如之前的例子在ObjectReader用ADO.NET实现了,那么也可以在ObjectReader中用EF实现数据操作。这个方法确实可以,也很不错。但是这个方法在分布式开发中(特别是在WCF中)有一点的局限性。例如你有一个界面,上面可以有很多的选项,如下:
在服务接口那边,你肯定不想定义N多差不多的接口方法:如
GetUserByName(string username);
GetUserByEmail(string email);
或者
GetUserByCondition(string username,string password,string email .....);
这样都是很不灵活的,如果User的属性减少了或者增多了,那么如果要在服务器那边暴露的接口的方法也要修改,这样终究是不好。如下采用下面的方法:
GetUserByCondition(Critera condition);
其中,Critera是条件对象。那么我们在客户端就可以任意构造条件对象,这个条件对象就把在它上面进行的操作记录下来,然后统一的交给GetUserByCondition方法去服务器解释并执行。此时,这个条件对象就是在客户端生成的,而且这个条件对象此时是不用去数据库中去执行的。如果条件对象是从IQueryable接口继承的,那么在客户端构造完条件对象之后,就要去数据库中执行了,如果再在ObjectReader搞个分布式调用,难度不说,也很别扭,这不是我们所要的。
所以,综合上面的一些考虑,那么可以确定:条件对象不继承IQueryable接口。但是我们又希望采用类似linq的操作,那么只有自己实现了。
本篇就暂时写到这里,因为太长了,所以分为前篇和后篇发布,因为博客园不能在一小时内发两篇,所以后篇将会在9点左右发布。希望大家见谅。
版权为小洋和博客园所有,,欢迎转载,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
前言:这个系列有段时间没有动了。主要是针对大家的反馈在修改代码。在修改的过程中,也有了一些新的体会,这里和大家分享一下,同时也发布一下业务框架的第一个版本。在本篇文章中,学习到的不是仅仅只是代码,而是设计的思想和实现这种思想的方法。在写本篇时有个感触:把一个东西彻底的讲清楚,不容易。希望大家
多提意见。而且在写本篇的时候,我个人也是很兴奋的,至于原因相信大家在看完之后就知道了。J
本篇的议题如下:
1. 打通业务层和数据层
2. 打通方法的选择和实现
3. 再次借鉴.NET Framework设计思想
4. 水到渠成
5. 代码的版本说明
系列文章链接:
[原创].NET 分布式架构开发实战之一 故事起源
[原创].NET 分布式架构开发实战之二 草稿设计
[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考
[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
[原创].NET 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之六 DAL的重构
[原创].NET 业务框架开发实战之七 业务层初步构想
[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
[原创].NET 分布式架构开发实战之二 草稿设计
[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考
[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
[原创].NET 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之六 DAL的重构
[原创].NET 业务框架开发实战之七 业务层初步构想
[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
1. 打通业务层和数据层
首先,回顾之前的文章一直讨论的问题:
1. 如何使得数据层”以不变应万变”。
2. 条件对象如何实现
3. 如何在业务层和数据层之间mapping数据
本篇就告诉大家,如何切切实实的解决上面三个问题。
首先,从一个图示开始讲述。
代码
public List<User> GetUserByAge()
{
ICriteria<User> conditionPerson =
CriteriaFactory.Create<User>().Where(u => u.Age < this.Age).OrderBy<string>(u => u.Name).Skip(8).Take(8);
return DataPortal.Query(conditionPerson);
}
上面的代码中,Create方法就是实例化一个ICriteria<User>,此时我们想做的仅仅只是一件事:把在 ICriteria<User>上的操作记录下来而已。然后把记录下来的结果解析,解析的最终结果就是一条sql命令,然后再给不同的DataProvider去执行。也就是说,在DataPortal内部可以配置用什么方法来执行数据操作:是直接使用ADO.NET执行sql命令,还是把sql命令给Entity Framework...通过配置决定。如果ICriteria<T>是从IQueryable接口进行了继承,那么在ICriteria实现这个结果的过程中就必须要去数据库中进行执行,因为Execute方法返回的是T的集合,而不是sql命令(字符串)。
大家可能想到:那就在Execute方法中去实现不同的DataProvider,例如之前的例子在ObjectReader用ADO.NET实现了,那么也可以在ObjectReader中用EF实现数据操作。这个方法确实可以,也很不错。但是这个方法在分布式开发中(特别是在WCF中)有一点的局限性。例如你有一个界面,上面可以有很多的选项,如下:
在服务接口那边,你肯定不想定义N多差不多的接口方法:如
GetUserByName(string username);
GetUserByEmail(string email);
或者
GetUserByCondition(string username,string password,string email .....);
这样都是很不灵活的,如果User的属性减少了或者增多了,那么如果要在服务器那边暴露的接口的方法也要修改,这样终究是不好。如下采用下面的方法:
GetUserByCondition(Critera condition);
其中,Critera是条件对象。那么我们在客户端就可以任意构造条件对象,这个条件对象就把在它上面进行的操作记录下来,然后统一的交给GetUserByCondition方法去服务器解释并执行。此时,这个条件对象就是在客户端生成的,而且这个条件对象此时是不用去数据库中去执行的。如果条件对象是从IQueryable接口继承的,那么在客户端构造完条件对象之后,就要去数据库中执行了,如果再在ObjectReader搞个分布式调用,难度不说,也很别扭,这不是我们所要的。
所以,综合上面的一些考虑,那么可以确定:条件对象不继承IQueryable接口。但是我们又希望采用类似linq的操作,那么只有自己实现了。
本篇就暂时写到这里,因为太长了,所以分为前篇和后篇发布,因为博客园不能在一小时内发两篇,所以后篇将会在9点左右发布。希望大家见谅。
版权为小洋和博客园所有,,欢迎转载,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
相关文章推荐
- [原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
- [原创].NET 业务框架开发实战之七 业务层初步构想
- [原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
- [原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- [原创].NET 业务框架开发实战之六 DAL的重构
- [原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- [原创].NET 业务框架开发实战之六 DAL的重构
- [原创].NET 业务框架开发实战之七 业务层初步构想
- [原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
- .NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- [原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
- [原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
- .NET 业务框架开发实战之七 业务层初步构想
- .NET 业务框架开发实战之八 业务层Mapping的选择策略
- .NET 业务框架开发实战
- 实战揭秘:开发.Net平台应用系统框架 (4)
- C#.net 地图控件开发(十二) 第一阶段总结,附代码示例