在WCF和Entity Framework周围进行一些实验。 几个问题。
选项1：
我知道实体框架类可以直接在WCF上进行序列化，从SP1开始。然而，我想知道在此过程中如何处理延迟加载、急切加载、上下文管理等方案，如果它们被处理的话？
选项2：
另一种选择可能是使用EFPocoAdapter，它在实体框架的基础上有一个简单的POCO包装器，而不是直接公开实体框架类。http://code.msdn.microsoft.com/EFPocoAdapter。有人使用过吗？您对此有何想法？
其他思考：
关于 ADO.NET 数据服务 - 据我了解，ADO.NET 数据服务不能通过远程配置 (nettcp 绑定)。它仅支持基于 http 的访问。我们都知道二进制序列化较慢。
有什么建议或其他选择吗？
我对此进行了一些挖掘，以下是我的调查结果。
ADO.NET 数据服务：
您可以使用ADO.NET数据服务（需要SP1）以几乎零代码的方式通过网络公开您的实体框架。但据我所知，唯一的限制是事务是基于HTTP的。这意味着在序列化方面存在一些开销（我们都知道二进制序列化更快），但优点是我们服务的实现速度。
我从 John [http://twitter.com/John_Papa] 这里得到了一个非官方消息 -“使用WCF有更多的选项。在大多数情况下需要更多的工作。Astoria可以轻松地暴露实体。大多数情况下性能差异可以忽略不计。”
优点-您实际上不需要编写任何服务-您只需将验证和安全逻辑钩子绕过数据服务和实体框架即可。如果您正在使用基于HTTP的数据中心服务-例如拥有Silverlight客户端或基于HTTP的Winform / WPF前端的情况下，这是理想的。
将实体框架公开到WCF。
随着SP1的推出，越来越多的支持使用实体框架在多层架构中进行就业。这包括支持急切的加载和上下文管理。当然，在这种情况下，我们需要编写服务（以及我们方法背后的逻辑）。或者，如果我们的实体框架模型与db完全对齐，我们可以生成大部分服务，包括我们需要的方法。
推荐您阅读此http://msdn.microsoft.com/en-us/magazine/cc700340.aspx。
另一个选择可能是使用EFPocoAdapter，将纯POCO包装器用于DTO的实体框架，而不是直接暴露实体框架类。现在它是一个指南针项目，用于Entity Framework的下一个版本 http://code.msdn.microsoft.com/EFPocoAdapter。
将此翻译成中文：将 EF 类暴露在 WCF 上是一个非常糟糕的想法。微软犯了一些严重的错误，阻止了这种方式成为有用的场景。他们将实体暴露为数据合同，但还暴露了实体的基础类，并为反向链接公开了两个副本。
另一方面，似乎ADO.NET数据服务具有一些魔力，可以让类似的工作实现。 本月的MSDN杂志中阅读SilverLight文章的客户端示例中使用ADO.NET数据服务。
不是为了挖旧帖子... 我在解决完全相同的问题时找到了这个列表。我们有WCF服务和一个Entity Framework域模型。最后，我基于Danny Simmons的工作制作了一个T4，它使用EDMX构建POCO消息类以及扩展方法，这些方法映射entity.ToMessage()和message.ToEntity（objectcontext）。
在.NET 4.0之前，这似乎是最好的中间方法，因为它不需要其他外部项目依赖项或像我发现的其他方法（基于PostSharp）需要跳跃的困境。
如果还有其他人认为这种方法会有帮助，请让我知道，我会在我们的googlecode网站上发布TT文件的链接。
