围绕 WCF 和实体框架做一些实验。几个问题。
选项 1：
我知道实体框架类可以直接通过 WCF 序列化，从 sp1 开始。但是，我想知道延迟加载、急切加载、上下文管理等场景是如何处理的，如果它们被处理的话？
选项 2：
另一种选择可能是使用 EFPocoAdapter，在实体框架之上有一个普通的 POCO 包装器，而不是直接公开实体框架类。 http://code.msdn.microsoft.com/EFPocoAdapter 。有人用过这个吗？对这个方向有什么想法吗？
其他想法：
关于 ADO.NET 数据服务 - 据我了解，不能通过远程处理（nettcp 绑定）配置 ADO.NET 数据服务？它仅支持基于 http 的访问。我们都知道二进制序列化比较慢。
任何指针或任何其他选项？
【问题讨论】：
标签： c# .net wcf entity-framework
我已经对此进行了一些挖掘，这是我对此的发现。
ADO.NET 数据服务：
您可以使用 ADO.NET 数据服务（您需要 SP1）通过网络公开您的实体框架，代码几乎为零。但据我了解，唯一的限制是，事务是通过 HTTP 进行的。这意味着，在序列化方面有一个小的开销（我们都知道二进制序列化更快），但优势是我们服务的实现速度。
我从 John [http://twitter.com/John_Papa] 那里得到了一个非正式的消息——“wcf 绝对有更多的选择。在大多数情况下也有更多的工作。Astoria 很容易暴露实体。在大多数情况下，性能差异可以忽略不计”
优点 - 您根本不需要编写任何服务 - 您只需围绕数据服务和实体框架挂钩验证和安全逻辑，我们就完成了。如果您通过 http 使用以数据为中心的服务是理想的选择 - 在诸如拥有 silverlight 客户端或通过 http 的 winform/wpf 前端等场景中。
通过 WCF 公开实体框架：
在 SP1 中，很多支持在分层架构中使用实体框架。这包括对预先加载和上下文管理的支持。当然，在这种情况下，我们需要编写服务（以及方法背后的逻辑）。或者如果我们的实体框架模型与数据库完全一致，我们可以生成大部分服务，其中包括我们需要的方法。
推荐你阅读这篇http://msdn.microsoft.com/en-us/magazine/cc700340.aspx
另一种选择可能是使用 EFPocoAdapter，在 dtos 的实体框架之上有一个普通的 POCO 包装器，而不是直接公开实体框架类。现在它是实体框架http://code.msdn.microsoft.com/EFPocoAdapter 的下一个版本的指南针项目。
【讨论】：
通过 WCF 公开 EF 类是一个非常糟糕的主意。微软犯了一些严重的错误，使这种情况无法成为有用的场景。他们将实体公开为数据合同，还公开了实体的基类，对于反向链接，公开了链接的两个副本。
另一方面，ADO.NET 数据服务似乎有一些魔力，可以让类似的东西发挥作用。阅读本月 MSDN 杂志中的 SilverLight 文章，了解从客户端使用 ADO.NET 数据服务的示例。
【讨论】：
不是要提出旧帖子，而是...我在处理完全相同的问题时发现了这个清单。我们有 WCF 服务和实体框架域模型。最后，我最终根据 Danny Simmons 的工作制作了一个 T4，它采用 EDMX 并构建 POCO 消息类以及映射 entity.ToMessage() 和 message.ToEntity(objectcontext) 的扩展方法。
这似乎是 .NET 4.0 之前最好的中间方法，因为它不需要额外的外部项目依赖项或像我发现的其他方法（基于 PostSharp）那样跳过的箍。
如果其他人认为这种方法会有所帮助，请告诉我，我会将指向 TT 文件的链接发布到我们的 googlecode 网站上。
【讨论】：