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

【问题标题】：Should I use Datasets or Entity Framework to transfer data via WCF services?我应该使用数据集还是实体框架通过 WCF 服务传输数据？
【发布时间】：2013-10-23 10:24:13
【问题描述】：

我正在进行应用程序设计并调查在 WCF 服务和 ASP.NET Web 应用程序之间传递数据的问题。我正在查看的选项是使用“数据集”或实体框架。

我有很多问题，

如果我使用实体框架来传递数据，是否会增加 WCF 通信的开销，
考虑到通信开销，数据集是否被视为“轻量级”，
如果我使用实体框架，如果我使用存储过程返回复杂数据，如何维护对象模型？

总的来说，我需要弄清楚使用这些技术的利弊。

【问题讨论】：

你的意思不是“数据集或实体框架”吗？

标签： wcf entity-framework strongly-typed-dataset

【解决方案1】：

您的问题涉及面向服务架构 (SOA) 的原则。在 SOA 中，服务应该公开通过契约应用于业务对象的操作（方法）。业务对象应以标准方式定义，这就是 WCF 使用 WSDL 和 XML Schema 来执行此操作的原因。

SOA 的一个原则是业务对象通过模式和/或合同共享，而不是作为特定的实现。根据这个原则，Dataset 是一个重量级的、.NET 特定的、面向数据库的对象，不应该用来表示业务对象。 Microsoft Patterns & Practices 小组显然无视 SOA 原则，因为它shows how to use Dataset as Data Transfer Objects. 无论他们只是在促进供应商锁定还是只是在破坏 SOA 的整个概念，这都是任何人的猜测。如果您的服务极有可能被非 .NET 客户端使用，请不要使用数据集。

如果您决定使用实体框架，那么我建议您使用Code First 来定义实体框架数据模型，并在您的服务中公开那些“代码优先”业务对象。这个SO question & answers 很好地讨论了将实体框架与 WCF 结合使用。

【讨论】：

如何构建一个实体模型来匹配合约并从数据库模式映射到合约？它将是模型优先的，但不会像 LINQ to SQL 那样直接公开数据库对象。否则，如果不是为了限制通过服务暴露的数据库的视图，你推荐代码优先的理由是什么？
很抱歉，如果有任何混淆。在首先推荐 EF 代码时，我的意思是实体模型类是 POCO，不需要从面向数据库的基类继承。这些实体模型类将是在 WCF 服务接口中作为协定公开的类。如果它们包含业务逻辑方法，尤其是构造函数中的逻辑，那么事情会变得更加棘手。对于这些情况，WCF 服务合同可能需要一个真正的、单独的 POCO DTO。

【解决方案2】：

您真的考虑上下传递整个数据集吗？这将破坏您的对象模型并且更难以维护，尽管我想您可以实现存储库模式。尽管如此，即使只是发送更改，您也需要做一些奇怪的事情，例如确保您不传输架构并且可能使用 compress 选项。但与 Entity Framework Code First 相比，它是一个非常糟糕的选择，在单独的程序集中具有干净的 POCO，并且没有任何 EF 基础设施污染 DTO。

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

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

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

【讨论】：