分層體系結構中的ASP.NET和實體框架 - 僅針對ORM使用實體框架

Question

我有一個ASP.NET應用程序，它使用分層體系結構，例如表示層，業務邏輯層，數據訪問層。

我不希望業務層必須知道數據訪問層是如何實現的，而且我不打算使用EntityDataSource或類似方法將實體直接綁定到數據控件。 （所以一個存儲庫模式場景）

我只是希望使用實體框架作爲生成類的ORM工具。我知道如何做到這一點。我不清楚的是

1. 是否建議通過應用程序傳播這些類，以便業務邏輯層將處理由實體框架直接創建的部分類？ （例如，如果我在sql中有一個客戶表，那麼實體fw將創建一個客戶類，它可能會直接在我的應用程序的所有層中使用）
2. 如何管理事務支持，如果我的BLL正在調用幾個不同的實體類但想把它當作一筆交易

Answer 1

1. 如果你很實際：是的！它將避免您雙倍映射工作和雙重映射產生的潛在錯誤。 （通過雙映射我的意思是DB - > ORM和ORM - >業務邏輯）。
2. 使用TransactionScope。這是進行交易而不必擔心嵌套交易的最佳方式。

Answer 2

不能與實體框架，但我曾試圖創建與分別在數據訪問層執行兩個插入存儲過程的樣品（使用數據訪問應用程序塊3.1），在服務/ BLL的TransactionScope上下文內包裹，它不起作用。一個插入通過，另一個插入失敗並且數據被提交。

你自己做這個事情有沒有成功？

Answer 3

我懷疑這可能是回答你的問題：

http://code.msdn.microsoft.com/EFPocoAdapter/Release/ProjectReleases.aspx?ReleaseId=1580

的工具生成一些沒有實體框架的依賴，你可以跨層傳遞類。

Answer 4

另一種方法是使用映射器類，使用EF純粹作爲數據訪問並使用僅在DAL內生成的類EF，然後通過映射器將這些DAL對象映射到BLL的對象。它適合我們。

Answer 5

現在使用新的EF4，您還可以使用POCO類，從而消除了在圖層之間映射實體的額外負載。在我們的應用程序中，我們使用了EF4，並在應用程序之外的應用程序中使用了視圖模型以外的業務實體。它顯着提升了性能。

Answer 6

即使您使用生成的POCO類，就像其他操作系統建議的那樣，您仍然必須對實體框架保持一定的依賴關係：發送到DbContext/ObjectContext的查詢。因此，您應該考慮將查詢封裝在存儲庫中。