分层体系结构中的实体框架?

我在这方面做了一些挖掘,以下是我的发现。

ADO.NET数据服务:

您可以使用ADO.NET数据服务(需要SP1)在线公开实体框架,几乎不需要任何代码。但据我所知,唯一的限制是,事务是通过HTTP进行的。这意味着,在序列化方面存在一些不足(我们都知道二进制序列化更快),但优势在于我们服务的实现速度。

我从约翰那里得到一个非正式的消息[ http://twitter.com/John_Papa] 关于这一点——“wcf肯定有更多的选择。在大多数情况下也有更多的工作。Astoria很容易暴露实体。在大多数情况下,性能差异可以忽略不计”

优点是——您根本不需要编写任何服务——您只需围绕数据服务和实体框架钩住验证和安全逻辑,我们就完成了。如果您正在通过http使用以数据为中心的服务,那么这是一个理想的选择—在类似silverlight客户端或通过http使用winform/wpf前端的场景中。

通过WCF公开实体框架:

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

建议你读一下这个 http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

http://code.msdn.microsoft.com/EFPocoAdapter .

在WCF上公开EF类是一个非常糟糕的主意。微软犯了一些严重的错误,使其无法成为一个有用的场景。他们公开了实体作为数据合同,但也公开了实体的基类,对于反向链接,公开了链接的两个副本。

不是提出一个旧的职位,但。。。我在处理完全相同的问题时发现了这个列表。我们有WCF服务和实体框架域模型。最后,我根据Danny Simmons的工作制作了一个T4,它采用EDMX并构建POCO消息类以及映射entity.ToMessage()和message.ToEntity(objectcontext)的扩展方法。

在.NET4.0之前,这似乎是最好的中间方法,因为它不像我发现的其他方法(基于PostSharp)那样需要额外的外部项目依赖项或环。