園子里這么多討論OO的﹐我也來湊一下熱鬧吧。

 
面向對象開發一個最重要的思想就是對真實世界進行模擬。

 
然而﹐在大量的使用面向對象語言開發的系統中﹐您卻很難看到這種模擬﹐而依然是些以數據庫為中心的增刪改查動作﹐很少能看到”真實的世界”的身影。

 
出現這種情況﹐很大程度上都是受數據庫為中心的影響。

 
以數據庫為中心開發系統﹐有一套成熟的理論﹐也經歷住了多年的考驗﹐是到今天為止﹐大部分信息系統開發時的不二選擇。

 
以一個圖書管理系統為例﹐有這樣的一些功能﹕新書上架﹐借閱﹐歸還。

 
按照數據庫方法﹐我們會設計出這樣的三個關系﹕

書籍(BookID,ISBN﹐書名﹐作者﹐出版社﹐內容簡介)

借書證(CardID﹐姓名﹐電話﹐身份證號﹐地址)

借閱(BookID,CardID,借閱時間,歸還時間,)

 
然后在數據庫中建表

 
接下來提供書籍新增﹐刪除﹐修改﹐查詢﹐借書證增刪改查﹐圖書借閱﹐歸還的人機界面

 
再圍繞數據庫編寫增刪改查對象和方法。大家爭論的Book.Save和BookManager.Save方法也是在此吧。其實只要不重復代碼﹐使用起來方便﹐高效﹐統一﹐無論將Save方法放在哪﹐都是有其道理的。

 
對于大部分信息系統﹐以數據庫為中心是十分合適的﹐這種方法也是非常高效且成熟。

 
然而﹐您還是可以嘗試另外一種方法

 
我們想象這樣的場景﹕

 
有一個 [圖書館]

[圖書館]里有很多[書架](可以理解為﹕書籍分類目錄)

[書架]上有很多[書籍]

一個讀者進入系統﹐系統幫助他瀏覽[圖書館]的[書架],然后在其中一個[書架]中找到了他想借閱的[書籍]﹐接下來﹐它將[借書證]交給管理員﹐要求借閱該[書籍]﹐管理員辦理借閱手續﹐產生一筆[借閱記錄]﹐完成借書過程

 
這個場景可以由下面這個對象完成

 
Class 圖書館幫助者

{

        Public List<書架> 所有書架

{

                Return 圖書館.Instance.所有書架  

        }

        Public void 選擇書架(書架)

        {

                記錄當前書架

}

Public void 選擇圖書(圖書)

{

記錄所選圖書
}

        Public void 借閱(借書證)

        {

                If(借書證.借出記錄!=null)

                        Throw Exception “該書已借出”;

                New 借閱記錄();

                借閱記錄.Book = 當前圖書

                借閱記錄.Card = 借書證

                借閱記錄.時間 = Now

                當前圖書.借出記錄 = 借閱記錄

                借書證的借閱記錄.Add(借閱記錄)

}

}

這就是借書的用例實現﹐而這些對象則是系統領域模型中的對象。

沒有數據庫﹐沒有UI﹐只有業務以及邏輯。

當您開發人機界面時﹐您可以選擇windows﹐也可以選擇web﹐它使用這個類 (顯示書架﹐選擇一個書籍﹐顯示書架中的書籍﹐選擇一本書﹐借閱按鈕)完成了借閱功能

自始至終﹐我們的設計中均未出現數據庫

我們的系統做為一個真實世界的模型﹐已經足夠.上架時﹐只要new 書籍﹐加入書架就可以﹐辦理借書證﹐也只需要new 借書證,同樣﹐歸還書籍時﹐只要將借出記錄與書籍的關聯取消即可﹐一切良好。

然而這種理想的環境是不存在的﹐這樣我們才有了對象持久化的概念﹐數據庫作為一個穩定﹐高效的持久方案﹐就是不錯的選擇(我以前也試過將所有對象以二進制文件形式間隔備份到硬盤上的方法完成持久)。

至于系統中的對象與數據庫的表格如何轉換﹐ORM就開始派上用場了。

然而請記住一條﹐在使用數據庫存對象時﹐請千萬不要和領域模型耦合在一起了(不要在借閱方法中﹐來一句Book.Insert代碼﹐我們的領域對象只是互相之間有關系﹐而和數據庫是沒關系的﹐我們的數據庫保存的是當前系統中的對象及其狀態)﹐設計模式呀﹐AOP呀﹐這時候是他們大顯身手的時候了

(順便說一句﹕一直以來﹐我認為以數據庫為中心而又采用ORM的系統設計方案可以說非常憋屈的﹐好好得實現您的增刪改查﹐下SQL﹐連數據庫不就行了﹐硬是插一腳O/R Mapping﹐讓十分強大的SQL,變成笨手笨腳的對象方法﹐不難受才怪。)