问我应该使用数据集或实体框架通过WCF服务传输数据吗？

EN

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

SOA原则是业务对象通过模式和/或契约共享，而不是作为特定的实现共享。根据这个原则，Dataset是一个重量级的、特定于.NET的、面向数据库的对象，不应该用于表示业务对象。微软模式与实践小组显然忽视了SOA的宗旨，因为它是演示如何使用Dataset作为数据传输对象。，无论它们是在推广厂商的锁定，还是只是破坏了SOA的整个概念，这是任何人的猜测。如果您的服务被非.NET客户端使用的可能性最大，请不要使用Dataset。

如果您决定使用实体框架，那么我建议您使用代码优先来定义实体框架数据模型，只需在服务中公开那些“代码优先”的业务对象。这个所以问题和答案很好地讨论了如何在WCF中使用实体框架。

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

EF不应该增加开销，但它取决于它是如何实现的，以及正在传递哪些数据对象。如果您将数据传递到上下文中，并在调用SaveChanges (如SaveChangesOptions.ReplaceOnUpdate )时使用正确的选项，则只会更新已更改的实体。执行的查询是有效的，只要您注意不要延迟加载您不需要的东西。您需要很好地理解LINQ到实体，并对更新进行批量处理，就像其他任何可能代价高昂的方法调用一样。在运行数据库分析器的情况下运行一些测试，以提高与EF交互的效率，监视IIS日志中的数据大小和传输时间等。

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

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