分層架構中的實體框架？

Question

圍繞WCF和實體框架進行一些實驗。 幾個問題。

選項1：

我知道實體框架類可以通過WCF直接序列化，sp1以上。 但是，我想了解如何處理延遲加載，急切加載，上下文管理等方案，如果它們完全處理的話？

選項2：

另一種選擇可能是使用EFPocoAdapter，在實體框架之上有一個普通的POCO包裝器，而不是直接暴露實體框架類。 http://code.msdn.microsoft.com/EFPocoAdapter 。 有人用過嗎？ 這個方向的任何想法？

其他想法：

關於ADO.NET數據服務 - 據我所知，ADO.NET數據服務無法通過遠程配置（nettcp綁定）進行配置？ 它僅支持基於http的訪問。 我們都知道二進制序列化速度較慢。

任何指針或任何其他選項？

Answer 1

我已經做了一些挖掘，這是我對此的發現。

ADO.NET數據服務：

您可以使用ADO.NET數據服務（需要SP1）通過線路公開您的實體框架，幾乎為零代碼。 但據我了解，唯一的限制是，事務是通過HTTP進行的。 這意味着，在序列化方面存在一個小問題（我們都知道二進制序列化更快），但優勢在於我們服務的實現速度。

我從約翰[ http://twitter.com/John_Papa]那里得到了一個非正式的詞 - “wcf肯定有更多的選擇。在大多數情況下也有更多的工作.Astoria很容易暴露實體。在大多數情況下，Perf差異可以忽略不計”

優點 - 您根本不需要編寫任何服務 - 您可以圍繞數據服務和實體框架掛鈎驗證和安全邏輯，我們就完成了。 如果你通過http消費以數據為中心的服務，那就太理想了 - 比如擁有一個Silverlight客戶端，或一個winform / wpf前端而不是http。

在WCF上公開實體框架：

使用SP1，在分層體系結構中使用實體框架有很多支持。 這包括對急切加載和上下文管理的支持。 當然，在這種情況下，我們需要編寫服務（以及我們方法背后的邏輯）。 或者，如果我們將實體框架模型與db完全一致，我們可以生成大多數服務，其中包括我們需要的方法。

建議你閱讀這篇http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

另一種替代方法可能是使用EFPocoAdapter，在dtos的實體框架之上有一個普通的POCO包裝器，而不是直接暴露實體框架類。 現在它是下一版Entity框架http://code.msdn.microsoft.com/EFPocoAdapter的指南針項目。

Answer 2

在WCF上公開EF類是一個非常糟糕的主意。 微軟做了一些嚴重的錯誤，以防止這是一個有用的場景。 他們將實體暴露為數據控制，但也暴露了實體的基類，對於反向鏈接，暴露了鏈接的兩個副本。

另一方面，似乎ADO.NET數據服務有一些神奇之處，可以讓它接近這個。 閱讀本月MSDN雜志中的SilverLight文章，從客戶端獲取使用ADO.NET數據服務的示例。

Answer 3

不要提起一個舊帖但是...我在處理完全相同的問題時找到了這個列表。 我們有WCF服務和Entity Framwork域模型。 最后，我最終制作了一個基於Danny Simmons工作的T4，它接受EDMX並構建POCO消息類以及映射entity.ToMessage（）和message.ToEntity（objectcontext）的擴展方法。

這似乎是.NET 4.0之前的最佳中間方法，因為它不需要像我發現的其他方法（基於PostSharp）那樣需要額外的外部項目依賴或跳躍。

如果有人認為這種方法有幫助，請告訴我，我會在googlecode網站上發布TT文件的鏈接。