EntityFramework ,ef 介紹

EntityFramework之領域驅動設計實踐

分層架構

在引入執行個體以前，我們有必要回顧，并進一步了解分層架構。“層”是一種體系結構模式[POSA1]，也是被廣大軟體從業人員用得最為廣泛而且最為靈活的模式之一。記得在CSDN上，時常有朋友問到：“分層是什麼？為什麼要分層？三層架構是不是就是表現層、業務邏輯層和資料通路層？”

到這裡，你可能會覺得這些朋友的問題很簡單，分層嘛，不就是将具有不同職責的元件分離開來，組成一套層内部高聚合，層與層之間低耦合的軟體系統嗎？不錯！這是分層的目标。但是，我們應該如何分層呢？

領域驅動設計的讨論同樣也是建立在層模式的基礎上的，但與傳統的分層架構相比，它更注重領域架構和技術架構的分離。

傳統的三層架構

如上文那位朋友提的問題那樣，最簡單的分層方式自然就是“表現層、業務邏輯層和資料通路層”，我們可以用下圖來表示這個思想：

注意圖中打虛線的“基礎結構層”，從實踐的表現上來看，這部分内容可能就是一些幫助類，比如 SQLHelper之類的，也可能是一些工具類，比如TextUtility之類。這些東西可以被其它各層所通路。而基于分層的概念，表現層隻能跟業務邏輯層打交道，而業務邏輯層在資料持久化方面的操作，則依賴于資料通路層。表現層對資料通路層的内容一無所知。

從領域驅動的角度看，這種分層的方式有一定的弊端。首先，為各個層面提供服務的“基礎結構層”的職責比較紊亂，它可以是純粹的技術架構，也可以包含或處理一定的業務邏輯，這樣一來，業務邏輯層與“基礎結構層”之間就會存在依賴關系；其次，這種結構過分地突出了“資料通路”的地位，把“資料通路”與 “業務邏輯”放在了等同的地位，這也難怪很多軟體人員一上來就問：“我的資料表該如何設計？”

領域驅動設計的分層

基礎結構層Infrastructure layer

領域層Domain layer

應用層Application layer

表現層Presentation Layer

• 基礎結構層：該層專為其它各層提供技術架構支援。注意，這部分内容不會涉及任何業務知識。衆所周知的資料通路的内容，也被放在了該層當中，因為資料的讀寫是業務無關的
• 領域層：包含了業務所涉及的領域對象（實體、值對象）、領域服務以及它們之間的關系。這部分内容的具體表現形式就是領域模型（Domain Model）。領域驅動設計提倡富領域模型，即盡量将業務邏輯歸屬到領域對象上，實在無法歸屬的部分則以領域服務的形式進行定義。有關領域對象和領域服務的内容，我會在接下來的案例中進行闡述
• 應用層：該層不包含任何領域邏輯，但它會對任務進行協調，并可以維護應用程式的狀态，是以，它更注重流程性的東西。在某些領域驅動設計的實踐中，也會将其稱為“工作流層”。應用層是領域驅動中最有争議的一個層次，也會有很多人對其職責感到模糊不清。比如，有些國外的開發人員會覺得，既然不包含領域邏輯，那又如何協調工作任務呢？我會在《應用層與實體事件》章節對這些問題進行探讨
• 表現層：這個好了解，跟三層裡的表現層意思差不多，但請注意，“Web服務”雖然是服務，但它是表現層的東西