在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值。　
??????? 在必要的情況下，如果非得進行空值操作，建議對數據庫的返回的空值，進行泛型改造。

　　在數據庫中，我覺得應該設定默認值的問題，并不是誰說了就誰是對了，當然，我的觀點或理論上的理解也可能是錯誤的，如果能夠指正，我當然也很高興，畢竟這也是一種進步。

轉載于:https://www.cnblogs.com/William_Fire/archive/2004/06/28/19072.html

總結

以上是生活随笔為你收集整理的简单声明一下。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。