1

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

我有一堆问题，

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

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

4

2 回答 2

4

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

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

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

于 2013-10-23T15:08:44.077 回答
1

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

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

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

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

于 2013-10-23T15:28:55.593 回答