我应该使用数据集还是实体框架通过WCF服务传输数据?

您的问题涉及面向服务体系结构(SOA)的原则。在SOA中,服务应该公开通过契约应用于业务对象的操作(方法)。业务对象应该以标准的方式定义,这就是WCF使用WSDL和XMLSchema来实现这一点的原因。

SOA的一个原则是,业务对象通过模式和/或契约共享,而不是作为特定的实现共享。根据这个原则,数据集是一个重量级的、特定于.NET的、面向数据库的对象,不应用于表示业务对象。微软模式&实践小组显然忽视了SOA原则,因为它 shows how to use Dataset as Data Transfer Objects. 他们是在推动供应商锁定,还是在破坏SOA的整个概念,这是任何人的猜测。如果您的服务最有可能被非.NET客户端使用,请不要使用数据集。

如果您决定使用实体框架,那么我建议您使用 Code First 定义实体框架数据模型,并在服务中公开那些“代码优先”的业务对象。这 SO question & answers 提供关于将实体框架与WCF一起使用的良好讨论。

你真的在考虑上下传递整个数据集吗?这将破坏您的对象模型,并且更难维护,尽管我认为您可以实现Repository模式。尽管如此,即使只是发送更改,也需要做一些奇怪的事情,比如确保不传输模式,也许还需要使用压缩选项。但是,与实体框架代码优先相比,这是一个非常糟糕的选择,因为实体框架代码第一在一个单独的程序集中有非常干净的POCO,并且没有任何EF基础设施污染DTO。

EF不应该增加这样的开销,但这取决于它是如何实现的以及传递什么数据对象。如果将数据传递到上下文中,并在 SaveChanges 被称为 SaveChangesOptions.ReplaceOnUpdate ,将只更新已更改的实体。执行的查询是有效的,只要你注意不要懒惰地加载你不需要的东西。您需要很好地理解LINQ to实体,并像处理任何其他可能昂贵的方法调用一样批量更新。在运行数据库探查器的情况下运行一些测试,并尝试提高与EF交互的效率,监控IIS日志的数据大小和传输时间等。

由于需要封装模式,数据集不被认为是轻量级的,可能有人会犯错误,在多个表中发送一整堆数据,包括依赖关系表。这些可能无论如何都需要在客户端或服务器上拉入——非常混乱!EF确实以合理的方式支持存储过程,因为它们可以是模型的一部分,并在需要保存特定实体时被调用。ORM将赞美您的OO设计,并带来更干净的代码。

此外,如果您正在做一些简单的事情,并且只需要CRUD,而没有太多的业务逻辑,请考虑WCF数据服务。