EntityFramework之領域驅動設計實踐（四）

預存程序 - 領域驅動的反模式

EntityFramework（EF）中有一項功能，就是能夠根據資料庫中的預存程序產生實體的行為（或稱方法，以下統稱方法）。我在本系列的第一篇博文中就已經提到，這種做法並不可取！因為預存程序是技術架構中的內容，而我們所關注的卻是領域模型。

Andrey Yemelyanov在其“Using ADO.NET EF in DDD: A Pattern Approach”一文中，有下面這段話：

In this context, the architect also identified the anti-pattern of using the EF (ineffective use): the EF is used to mechanically derive the domain model from the database schema (database-driven approach). Therefore, the main topic of the guidelines should be the domain-driven development with the EF and the primary focus should be on how to build a conceptual model over a relational model and expose it to application programmers.

黑體部分的意思是：（被採訪的架構師）同時也指出了使用EF的一種“反模式”，即通過使用資料庫結構來機械化地產生領域模型（資料庫驅動的方式）。這也就證明了我在第一篇文章中指出的“只能通過領域模型來映射到資料模型，反過來則不行”的觀點。

我能夠理解很多做系統的朋友喜歡考慮資料庫方面的事情，畢竟資料存放區也是軟體系統中不可或缺的部分（當然，記憶體資料庫另當別論），資料庫結構設計的好壞直接影響到系統的運行效率。比如：加不加索引、如何加索引，將對查詢效率造成重大影響。但請注意：你把過多的精力放在了技術架構上，而原本更重要的業務架構卻被扔到了一邊。

什麼時候選擇預存程序？我認為預存程序的操作對象應該是資料，而不是對象，業務層也不可能把業務對象交給資料庫去處理。其實，預存程序本身的意義也就是將資料放在DB伺服器上處理，以減少客戶程式與伺服器之間的網路流量和往返次數，從而提高效率。所以，可以把查詢次數較多的、與業務無關的資料處理交給預存程序（比如資料統計），而不要單純地認為預存程序能夠幫你解決商務邏輯問題，那樣做只會讓你的領域模型變得混亂，久而久之，你將無法應對複雜的商務邏輯與需求變更。

在做技術選型的時候還要注意一點，也就是預存程序的資料庫相關性。預存程序是特定於某種關係型資料庫機制的，比如，SQL Server的預存程序與Oracle的預存程序並不通用，而有些資料庫系統甚至不支援預存程序。因此過多使用預存程序將會給你帶來一些不必要的麻煩。我個人對是否使用預存程序給出如下幾點意見：1、根據需求來確定；2、不推薦使用；3、出於效率等技術考慮，需要使用的，酌情處理。

回過頭來看Entity Framework，雖然現在支援從資料庫預存程序產生實體方法的過程，但這是一種反模式，我也不希望今後EF還提供將實體方法映射到預存程序的功能，因為行為不同於資料，資料是狀態，而行為是業務，它與領域密切相關，它不應該被放到“基礎結構層”這一技術架構中。