分层架构中的实体框架？

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 framework 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文件的链接。