[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
2014-03-12 20:07
417 查看
原文:[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略.NET 业务框架开发实战之八 业务层Mapping的选择策略
前言:在上一篇文章中提到了mapping,感觉很像在重新实现NHibernate。其实文章的本意是想反映出Richard在思考的时候的一些选择:利用现有的,还是最后自己用别的方式实现。如果一上来就说什么什么好,那太武断了,也很片面,系列文章反复的在强调一点:技术有它的适用场景,没有完美的技术。很多的朋友说本系列在近似的开发一个ORM,其实不是:ORM就是把数据库表转为数据实体,但是本篇中是使用已经转换后的数据实体。是把数据实体的数据给业务类。
而且本篇讨论业务类中的mapping,也就是数据的获取方式,当然,业务类的设计远远不止这些。
开始之前希望在这下面的两点上达到共识:
1. 最好不要把DAL的数据实体(Linq或者Entity Framework生成的),或者原生的DataTable暴露给UI那边(除非一定要,或者有特殊的原因)。
2. UI使用的是BLL类(或者基于消息的Scheme格式)。
今天的议题如下:
1.第二种Mapping方法。
2.第三种Mapping方法。
系列文章链接:
1.第二种Mapping方法。
Richard思考了配置文件的方式,诚然用配置文件确实灵活,但是灵活也是有代价的,因为Framework最后还得公司的开发人员使用,过多的配置和过高的学习成本使得Framework失去了很大的意义。
Richard开始思考了,想到了还有一种最简单的mapping的方式:就是直接一个个的赋值,如:
代码
public static readonly PropertyInfo<int> ProductIdProperty = RegisterProperty(
typeof(Product),
new PropertyInfo<int>("ProductId",typeof(M_Product)","Id"));
public string ProductId
{
get { return ReadProperty(ProductIdProperty); }
set { LoadProperty(ProductIdProperty, value); }
}
上面的代码通过生成的方式就比较方便,而且上面的属性声明还有更多其他的用途。初一看和WPF中依赖属性很像,确实思路也是从WPF借鉴而来的。这里简称“Mapping属性”。
今天就写到这里,真是对不住大家,因为本篇写的比较的啰嗦,而且还没有写完。下篇讲述Mapping属性的实现原理和原因,就是为什么要是用ProductIdProperty那种声明方式。
版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
前言:在上一篇文章中提到了mapping,感觉很像在重新实现NHibernate。其实文章的本意是想反映出Richard在思考的时候的一些选择:利用现有的,还是最后自己用别的方式实现。如果一上来就说什么什么好,那太武断了,也很片面,系列文章反复的在强调一点:技术有它的适用场景,没有完美的技术。很多的朋友说本系列在近似的开发一个ORM,其实不是:ORM就是把数据库表转为数据实体,但是本篇中是使用已经转换后的数据实体。是把数据实体的数据给业务类。
而且本篇讨论业务类中的mapping,也就是数据的获取方式,当然,业务类的设计远远不止这些。
开始之前希望在这下面的两点上达到共识:
1. 最好不要把DAL的数据实体(Linq或者Entity Framework生成的),或者原生的DataTable暴露给UI那边(除非一定要,或者有特殊的原因)。
2. UI使用的是BLL类(或者基于消息的Scheme格式)。
今天的议题如下:
1.第二种Mapping方法。
2.第三种Mapping方法。
系列文章链接:
[原创].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.第二种Mapping方法。
Richard思考了配置文件的方式,诚然用配置文件确实灵活,但是灵活也是有代价的,因为Framework最后还得公司的开发人员使用,过多的配置和过高的学习成本使得Framework失去了很大的意义。
Richard开始思考了,想到了还有一种最简单的mapping的方式:就是直接一个个的赋值,如:
代码
public static readonly PropertyInfo<int> ProductIdProperty = RegisterProperty(
typeof(Product),
new PropertyInfo<int>("ProductId",typeof(M_Product)","Id"));
public string ProductId
{
get { return ReadProperty(ProductIdProperty); }
set { LoadProperty(ProductIdProperty, value); }
}
上面的代码通过生成的方式就比较方便,而且上面的属性声明还有更多其他的用途。初一看和WPF中依赖属性很像,确实思路也是从WPF借鉴而来的。这里简称“Mapping属性”。
今天就写到这里,真是对不住大家,因为本篇写的比较的啰嗦,而且还没有写完。下篇讲述Mapping属性的实现原理和原因,就是为什么要是用ProductIdProperty那种声明方式。
版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
相关文章推荐
- 科大讯飞(语音合成和语音听写)
- android之横屏、全屏
- Cocoa Touch 入门记——《精通 iOS 开发》学习心得(4) [应用程序设置]
- 我的第一款iOS App: 极简天气 1.0
- Android系统进程Zygote启动过程的源代码分析
- [IOS]从相册或相机获取图片
- [Unity3D插件]2dToolKit系列三 碰撞检测功能的实现以及障碍物的随机摆放 推荐
- [Unity3D插件]2dToolKit系列三 碰撞检测功能的实现以及障碍物的随机摆放
- NSNumber的常用方法
- android之动态设置控件高宽
- android4.0下serial port给应用操作完成特殊定制
- iOS中assign、copy 、retain等关键字的含义
- android SDK安装后设置环境变量
- android多线程的实现方法
- Android初学常见问题
- cocos图片描边的方法
- Android ndk-gdb 调试
- (原创)Windows下使用android ADT工具dmtracedump.exe绘图
- iOS项目开发过程中的目录结构
- Unity3D学习,iTween范例1 AccurateLob