当前位置:主页   - 电脑 - 网站开发 - ASP.Net
DNN 数据访问策略(二)
来源:网络   作者:   更新时间:2012-03-10
收藏此页】    【字号    】    【打印】    【关闭

  空处理

  每一个数据存取系统都有一个特殊的构造来处理那些没有明确指定的字段值。

  在大多数关系数据库管理系统中,这个构造就是众所周知的null值。从应用程序的角度看,在表述层和数据存取层传递null值是一个架构上的挑战。这是因为表述层必须从数据库的特定信息抽象出来;而且,当一个属性值没有明确指定的时候表述层也必须能够表达说明。事实上这相当复杂,.NET Framework的本身的数据类型不能自动的转换从数据库返回的null值(如果你试图直接那样赋值的话将会抛出一个异常)。另外,每一个数据存储都有它自己的属性来实现null。唯一合理的解决方案就是创建一个抽象的传输服务,来编码/解码应用程序各层之间的null值。

  乍一看,你也许会想到用vb.net中的“nothing”关键字可以很好的担负起这个传输服务的任务。不幸的是,调查显示,.NET Framework本身的数据类型处理“nothing”的时候没有预想的那么好。尽管分配为nothing的属性不会抛出异常,实际上这个属性的值将非常依赖于它的数据类型(String = Nothing, Date = Date.MinValue, Integer = 0, Boolean = False, 等等)并且自带的IsNothing()函数的结果还不是一致的(兼容的)结果。

  在DNN里,我们创建了一个通用的类来处理null的问题,它统一管理应用程序各层的null问题。在应用程序中用一个常量来描述每种数据类型的null情况,再把这个常量转化成各种数据存储实现里的实际的null值。这个类包含的各种方法将null转换服务的物理细节从应用程序中抽象出来了。

  * 记住,这个类仅仅用在数据库字段允许有null值的情况下。还要记住,这个类要求DAL和BLL层之间的数据类型一致(例如:一个BLL信息类里的属性字段的数据类型必须跟DAL 数据提供者传递过来的参数的数据类型一致)。

其它资源
来源声明

版权与免责声明
1、本站所发布的文章仅供技术交流参考,本站不主张将其做为决策的依据,浏览者可自愿选择采信与否,本站不对因采信这些信息所产生的任何问题负责。
2、本站部分文章来源于网络,其版权为原权利人所有。由于来源之故,有的文章未能获得作者姓名,署“未知”或“佚名”。对于这些文章,有知悉作者姓名的请告知本站,以便及时署名。如果作者要求删除,我们将予以删除。除此之外本站不再承担其它责任。
3、本站部分文章来源于本站原创,本站拥有所有权利。
4、如对本站发布的信息有异议,请联系我们,经本站确认后,将在三个工作日内做出修改或删除处理。
请参阅权责声明