在構建乙個三層架構的系統的時候，實體的設計，是完全的物件導向，還是採用id關聯的平板物件，這是乙個問題。寫一點個人的觀點。
假設在乙個使用者管理系統中，存在單位和使用者兩個實體,
表結構如下：
我們先看物件關聯情況下實體的設計：
//////
單位實體
///
public
class
orgset
}private
string
_orgname;
//////
單位名///
public
string
orgname
set}
private
org _parentorg;
//////
父單位///
public
org parentorg
set}
private
ilist
<
org>
_childrenorg;
//////
子單位列表
///
public
ilist
<
org>
childrenorg
set}
private
ilist
<
user
>
_users;
//////
單位的使用者
///
public
ilist
<
user
>
users
set}}
//////使用者實體
///
public
class
user
set}
private
string
_username;
//////
使用者名稱///
public
string
username
set}
private
org _ownerorg;
//////
使用者所屬的單位
///
public
org ownerorg
set}
這是兩個非常物件導向的實體--資料實體，那麼我們在使用的時候會遇到什麼問題呢？
物件關聯在一起，不可避免的遇到關聯載入的問題--當我獲取乙個使用者實體的時候，為滿足完整性，我也必須從資料庫中取出乙個單位實體。
為了解決這麼問題，大多數流行的orm框架提供了lazy-load特性--延遲載入，只有當真正訪問到管理物件的時候才把物件從資料庫中取出來。
看似問題解決了，仔細分析一下，那些延遲載入實現的怎麼樣？？？
實現lazy-load的大多數方法都要求侵入實體**，如nhibanate，它的實體類屬性要求必須是虛屬性（最新版的nh），為什麼？應為它要延遲載入，就必須攔截屬性的呼叫（好像它是利用castle的動態**實現的）。
可能你會說，實體類屬性都寫成虛的（virtual）還是可以接受的，那麼，我們看另外的問題：
問題1：要延遲載入，取出乙個實體後，資料庫連線一定不能立即關閉， 資料庫連線關閉了，**還怎麼延遲訪問資料庫取資料？於是，資料庫連線關閉的**必須寫到ui層。
問題1：現在流行的一下aop，ioc框架很多都支援分布式部署，在分布式部署的情況下，我們考慮關聯實體會怎麼樣？遠端的乙個客戶端取到實體，每次訪問其他關係實體屬性時都會在一次請求伺服器端！
你可能會說，在分布式部署的情況下我不採用延遲載入不就可以了。請注意一點：
這裡所說的在aop框架支援下的分布式部署，是「透明」的分布式部署，即ui層開發的時候不需要要考慮分布式的問題（那麼，你是不是要延遲載入了），系統開發好了，如果需要，可以通過配置aop框架實現分布式，這時，原有的採用延遲載入的頁面就會碰到問題。
我們再看id關聯情況下實體的設計：
//////單位實體
///
public
class
orgset
}private
string
_orgname;
//////
單位名///
public
string
orgname
set}
private
int_parentid;
//////
父單位id
///
public
intparentid
set} }
//////使用者實體
///
public
class
user
set}
private
int_orgid;
//////
所屬單位id
///
public
intorgid
set}
private
string
_username;
//////
使用者名稱///
public
string
username
set}}
首先從**上，比上面的簡單些吧。
這樣的實體，雖然有那麼一點不「物件導向」，但絕對避免了「物件導向」時遇到的問題。
我們這群人的工作，總是在
發現問題-〉解決問題-〉引起新的問題 -〉解決問題 中度過的。
ok，id關聯的實體設計方法同樣遇到了新問題：我要處理多表的資料怎麼辦？我要跨表查詢怎麼辦？
解決方案就是：採用關聯實體，或者稱為檢視實體.
舉個例子: ui層要顯示乙個使用者列表, 同時顯示出每個使用者所屬的組織機構名 , 怎麼辦?
easy! 只要設計乙個關聯實體:
//////具有單位名稱的使用者關聯實體
///
public
class
userwithorginfo : user
set}}
或許,你要說,我不需要這麼多屬性,使用者的屬性加上單位的屬性太多了,ui層顯示的時候根本不需要!
ok,我們可以建立乙個檢視實體:
//////使用者檢視實體
///
public
class
userview
set}
private
string
_orgname;
//////
單位名///
public
string
orgname
set}}
這下滿足了吧！ 需要幾個屬性,就返回幾個屬性.
問題解決了!!!!!!!!!
但是新的問題又來了:
採用id關聯設計實體,仍然要寫大量的資料庫操作**,如果採用一些orm框架,他們對id關聯的實體設計又沒有考慮到進行支援,因為現有的orm框架大多都是為了應對「物件導向」的實體設計而開發的. nhibenate,ibatics.net,nbear，dlinq皆如此。
這就是dbo的由來，沒有人會做無用功，也不會有人喜歡發明乙個一樣的輪子，每個輪子都應該有它適合走的道路。
dbo，為id關聯實體設計提供資料操作支援的orm工具。
dbo從2007-5-20開始開發，基本功能完成，不足之處總歸是有的，任者見任，智者見智，歡迎有興趣的朋友提出意見。
dbo 介紹，見：
物件導向 設計原則 設計模式 程式設計規範 重構的關係
1物件導向程式設計因為其具有豐富的特性 封裝 抽象 繼承 多型 可以實現很多複雜的設計思路，是很多設計原則 設計模式編碼實現的基礎。1 物件導向的四大特性 封裝 抽象 繼承 多型 2 物件導向程式設計與面向過程程式設計的區別和聯絡 3 物件導向分析 物件導向設計 物件導向程式設計 4 介面和抽象類的...
實體與值物件
實體 在時間上有連續性，並且有唯一標識可以來區分的物件。值物件 用來描述事物的，不區分誰是誰的，不可變的物件。判斷乙個物件是實體還是值物件，還要根據它在具體的業務領域中的實際意義來決定，比如 體育館裡的座位，當業務領域這樣規定，一張門票對應乙個特定的座位，即每個座位都應該嚴格區分誰是誰，觀眾在選擇座...
實體物件的變更
原本準備通過乙個基類用子類進行拓展的方式來規劃不同 上爬取的商品，資料庫實現上用hibernate的joined subclass。父表儲存所有共同資訊，子表主鍵為父表主鍵，存不同特異資訊。後來發現其實每個子表的多餘資料都是它在相關 的id和買的鏈結所屬電商，id可直接在原表中賦值，所屬電商實際上沒...