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、出於效率等技術考慮，需要使用的，酌情處理。
回過頭來看實體框架，雖然現在支持從數據庫存儲過程生成實體方法的過程，但這是一種反模式，我也不希望今後EF還提供將實體方法映射到存儲過程的功能，因為行為不同於數據，數據是狀態，而行為是業務，它與領域密切相關，它不應該被放到“基礎結構層”這一技術架構中。
