问分层架构中的实体框架？

EN

我对此做了一些调查，这是我对此的发现。

ADO.NET数据服务：

您可以使用ADO.NET数据服务(您需要SP1)在线路上公开您的实体框架，代码几乎为零。但据我所知，唯一的限制是，事务是通过HTTP进行的。这意味着，在序列化方面有一个很小的优势(我们都知道二进制序列化更快)，但是它的优势是服务实现的速度更快。

我从John [http://twitter.com/John_Papa]那里得到了一个非正式的消息--“在wcf上肯定会有更多的选择。在大多数情况下也会有更多的工作。Astoria很容易暴露实体。在大多数情况下，Perf差异是可以忽略的。”

这些优点--您根本不需要编写任何服务--您只需将验证和安全逻辑与数据服务和实体框架挂钩，我们就完成了。理想的情况是在http上使用以数据为中心的服务，比如拥有silverlight客户端，或者在http上使用winform/wpf前端。

在WCF上公开实体框架：

使用SP1，在分层体系结构中使用实体框架有很多支持。这包括对急切加载和上下文管理的支持。当然，在这种情况下，我们需要编写服务(以及方法背后的逻辑)。或者，如果我们的实体框架模型与db完全一致，我们可以生成大部分服务，其中包括我们需要的方法。

建议您阅读此http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

另一种选择可能是使用EFPocoAdapter，在dtos的实体框架之上有一个普通的POCO包装器，而不是直接公开实体框架类。现在，它是实体框架http://code.msdn.microsoft.com/EFPocoAdapter下一个版本的指南针项目。

在WCF上公开EF类是个非常糟糕的主意。微软犯了一些严重的错误，使其无法成为一个有用的方案。它们已经将实体公开为数据控件，但也公开了实体的基类，对于反向链接，则公开了链接的两个副本。

另一方面，ADO.NET数据服务似乎有一些魔力，可以让接近它的东西工作。阅读本月Magazine中的SilverLight文章，了解使用ADO.NET数据服务的客户端示例。

不是为了提个旧职位但是..。在处理完全相同的问题时，我发现了这个列表。我们有WCF服务和实体框架域模型。最后，我在丹尼·西蒙斯的工作基础上制作了一个T4，它使用EDMX并构建POCO消息类以及映射entity.ToMessage()和message.ToEntity(对象上下文)的扩展方法。

这似乎是.NET 4.0之前最好的中间方法，因为它不需要像我找到的其他方法(基于PostSharp)那样需要额外的外部项目依赖或循环。

如果其他人认为这种方法会有帮助，请告诉我，我将在我们的googlecode站点上发布到TT文件的链接。