简单声明一下。

  在http://www.cnblogs.com/progame/archive/2004/06/27/19062.aspx的帖子中,反驳了我的观点,无可厚非,各人的观点不同嘛。不过,我想说明一点:我是搞快速开发的,是在保证工程质量前提下进行尽量的快速开发,所以有一些观点是涉及到一些技巧的,但也这些技巧与观点均建立在面向对象的思想之上。
  对于
progame的txtName.Text = Employee.Name & “”写法,我没有任何反对意见,这倒是一个不错的写法

  不过,从纯对象角度来说,“NULL并不表示这个属性没有,而是说这个属性暂时“未知”,比如说员工表的出生日期字段,用default?1900-01-01?还是1990-01-01? 难道这种默认值就不需要前台程序判断?”,如果是这样理解属性为空的概念也未尝不可,但是这样,在进行业务建模时,就应该将有Null值的属性列采用虚类进行描述,可以参考一下
对象/关系映射--继承模式中指出的One Inheritance Path One Table模式,在这里模式中,虚类是不能映射到表的,原因就是我们用的是关系型数据库,而不是对象型数据库,在关系型数据库中,一般不会出现可变化的虚表,当然也可以从其它手段进行模拟,不过,这如同用C来写对象化的编程一样,毕竟要麻烦一些。
  上面说的员工表的出生日期字段,用1900-01-01还是1990-01-01,我认为既然站在了对象的角度来看,就不应该考虑作为对象的“员工的出生日期”的是1900-01-01还是1990-01-01,属性本身是不应有指定的数据格式,因为属性只是一个描述,像1990-01-01这类格式字段,本身也是作为“出生日期”的属性信息而存储于数据库之中的。而且,默认值似乎也不会影响到实际应用程序中的操作,可能
progame老兄习惯于使用数据绑定操作进行数据库的操作,所以会遇到默认值选择什么比较好的问题。但请稍注意一下,属性的默认值,不一定是直接用于数据呈现而用的,它的作用是填充数据库中属性里残缺的部分,在关系型数据库与外部程序连接时,如果少了数据库的默认值,它在直接访问时的逻辑上更大的情况不是表示出了不存在,而表示出了未知。

eg. 在员工表中,假设,家庭住址为空,那么在此情况,如果应用程序请求员工的家庭住址的值时,数据库直接返回一个空标识,这时,在应用程序中,如果有一个对象接收到此空标识时,这个空标识作为object时,是null值,对象引用为空值,表达的直接逻辑就是不存在,而不应该是未知。按我的思想,一般的情况下,你不应该能够进行如下形式的声明(伪代码说明):
string str = null;
object o = (object)str;

上面的代码对一个string类型的对象进行装箱操作,但实际上,对于object本身来说是一个引用型,当对str进行装箱后,它实际上是对一个null进行了装箱操作,所以这是不应该能够实现的代码,但在.net的C#代码中,为什么编译能够通过?
在CLR中,是如下的操作:
  .maxstack  1
 
.locals init ([0] string str,
           [1] object o)
  IL_0000:  ldnull
  IL_0001:  stloc.0
  IL_0002:  ldloc.0
  IL_0003:  stloc.1

        请注意上面的颜色标识部分,([0] string str, [1] object o)发现了什么?对,[0]string str,0长度大小的string,这是CLR的自动转换,并且,还可以看到[1] object o,这是外部进行的装箱,也就是说,这里并不是类型转换,而是外部的一个包装而已。这样,应用程序中实际执行的代码与数据库中提交过来的数据,实际上已经被“污染”过了,这是无法实现高效的O/R映射的。因为在关系数据库中有数据类型的概念,其中分开了空值与0长度大小的概念,就关系型数据而言,空值确实是表示不存在,因为它返回的不是一个string的数据类型的空值,而返回的就是一个Null值。 
        在必要的情况下,如果非得进行空值操作,建议对数据库的返回的空值,进行泛型改造。

  在数据库中,我觉得应该设定默认值的问题,并不是谁说了就谁是对了,当然,我的观点或理论上的理解也可能是错误的,如果能够指正,我当然也很高兴,毕竟这也是一种进步。

posted @ 2004-06-28 00:09  一根神棍研古今  阅读(1137)  评论(4编辑  收藏  举报
Web Counter