|
|
最新發布的 Entity Framework 4.1 和新的 Code First 開發模式打破了服務器程序開發的基本規則：如果數據庫沒有準備就緒，不要輕舉妄動(Don’t take a single step)。Code First 允許開發人員重點關注業務領域并根據“類”(class)來為該領域建模。在某種程度上， Code First 模式鼓勵在 .NET 環境中應用“領域驅動設計 (DDD) ”原則。業務領域由相互關聯的實體構成，這些實體通過屬性對外公開自己的數據，通過方法和事件對外公開自己的行為。更重要的是，每個實體都可能處于某一狀態，并且與一組動態的驗證規則相綁定。
為實際應用場景編寫對象模型會面臨一些在演示程序和教程中沒有涉及的問題。在本文中，我將挑戰這些問題，并討論如何構建 Customer 類，我會就此簡要介紹一些設計模式和設計實踐，例如Party模式、聚合根(aggregate roots)、工廠(factories)以及代碼協定(Code Contracts)和企業庫驗證應用程序塊 (VAB) 等技術。
有一個開源項目可以作為參考，這里討論的代碼就是其中的一小部分。 它就是由 Andrea Saltarello 創建的 Northwind Starter Kit 項目 (nsk.codeplex.com) ，該項目旨在介紹構建多層解決方案的有效實踐。
對象模型(Object Model) vs. 領域模型(Domain Model)
爭論是使用對象模型還是領域模型似乎沒有意義，在大多數情況下，這只是一個術語表述問題(terminology)。 但準確地使用術語是確保團隊所有成員在使用特定術語時始終遵循同一概念的重要因素。
對于軟件行業的幾乎每個人而言，對象模型是一個具有共性的并且可能相關的對象的集合。領域模型有何不同？ 域模型歸根結底仍然是一個對象模型，因此，交替使用這兩個術語可能不會產生嚴重的錯誤。但在專門強調使用“領域模型”一詞時，它可能會使大家對所構建的對象的形態(shape)產生某些期望。
領域模型的這種用法與 Martin Fowler 給出的以下定義相關：
由行為和數據組合而成的領域的對象模型。相應地，這些行為用于表達業務規則和特定的業務邏輯（請參閱 P of EAA page 116）。
An object model of the domain that incorporates both behavior and data. In turn, the behavior expresses both rules and specific logic.
DDD 向領域模型中添加了一些實用的規則。從這個角度看，領域模型不同于對象模型，它更多推薦使用值對象(value objects)而不是基元類型(primitive types)。例如在對象模型中，一個整數可能具有多種含義，它可能表示溫度、金額、大小或數量。而在領域模型中，針對各種不同的場景會使用特定的值對象類型。
此外，領域模型需要識別出聚合根。聚合根是一個通過組合其他實體而得到的實體。聚合根中的對象與外部沒有直接的關聯，也就是不存在這樣的用例——不經過根對象而直接使用這些對象。比如，Order 實體就是一個典型的聚合根。 Order 包含聚合的 OrderItem，而不包含 Product。 難以想象您使用一個OrderItem 而它并不來自 Order（即使這只是由specs決定的，譯者注：也就是通過規約查詢直接得到相應的OderItem）。另一方面，您很可能具有這樣一些用例，您在其中使用不涉及訂單的 Product 實體。聚合根負責維護處于有效狀態的子對象并持久化這些對象。
最后，某些領域模型類(class)可以提供用于創建新實例的公共工廠方法，而不是構造函數。如果模型類通常是獨立的并且實際上不是層次結構的一部分，或者用于創建該類的步驟只是與客戶端相關，則可以使用普通的構造函數。但是，在使用聚合根這樣的復雜對象時，您還需要實例化之外的其他抽象級別。 DDD 引入了工廠對象（簡單一些的話，可以使用類中的工廠方法）方式，這種方式可將客戶端的需求與內部的對象及其關系和規則分離開來。可以在 An Introduction to Domain Driven Design 中找到有關 DDD 的清晰簡要的介紹。
Party模式
讓我們重點分析一下 Customer 類。 根據上文所述，此處是可能的簽名：
public class Customer : Organization, IAggregateRoot
{
...
}
NET技術：Dino Esposito: 一個領域模型的設計，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
