DataSets vs DataClasses 作为 WCF 服务的返回类型答案

【问题标题】：DataSets vs DataClasses as return type from WCF servicesDataSets vs DataClasses 作为 WCF 服务的返回类型
【发布时间】：2012-01-26 08:27:43
【问题描述】：

我需要通过 WCF 服务将信息从 BL 层传递到表示层。

我想通过 DataSets 来做，但我看到人们说这是一种不好的做法，建议使用数据类。

谁能解释一下区别和优势。

感谢您的帮助。

【问题讨论】：

标签： c# .net wcf wcf-data-services

【解决方案1】：

DataSet 是一种老式的、过时的类似 OR/M 解决方案，在拖放开发中长期运行良好。

一旦您想使用 WCF 或任何其他框架在服务上公开一些逻辑，您需要考虑到这些不应传输无用的数据，而只是客户端需要使用的数据，并且客户端可以是 用户界面或只是另一个服务或后端引擎。

在像 WCF 这样的服务中，最好的方法是 DTO（data-transfer objects，也称为 value objects），这是一个轻量级的- 业务对象的重量版本，与任何层完全不链接（它不依赖于业务、UI、数据......），可以轻松序列化为 XML 或 JSON 并在任何平台上反序列化，不仅在强类型环境中，但也有解释的、动态类型的，如 JavaScript、PHP、Python 或 Ruby（或许多其他）。

将 DTO 视为一个类，它具有某些消费者需要与您的服务层一起使用的确切数量的属性。

实际示例： 你有一个 Person 类，它有一个 Name、SecondName 和 Age。在您的用户界面中，您需要查询一些服务以获取 Person 列表，并且您只需要显示 SecondName。在这种情况下，您将设计一个具有单个属性 SecondName 的类，并且您将避免通过服务层向用户界面提供完整的 Person，因为它更便宜，而且显然是最优的。

如果此服务层返回 PersonDto 对象，则 3 人的 JSON 序列化列表将为 [{ "SecondName": "Blah" }, { "SecondName": "Bleh" }, { "SecondName": "Blih" }]。我不认为 DataSet 会是那么轻松的序列化。

查看这些关于DTO的文章：

【讨论】：

我几乎同意——只是数据检索服务应该使用 ODATA，并且使用 ODATA，用户可以过滤掉属性，因此不需要单独的“仅姓氏”dto。 .NET 原生支持 OData 已有一段时间了。
@TomTom 我不知道这个标准。感谢您的信息！

【解决方案2】：

我在博客上写过这个here

【讨论】：

【解决方案3】：

尝试一下 - WCF 服务应该独立于平台，而 DataSet 则不是。您不使用 DataSet 传输定义的文档，而是传输 .NET 特定对象的内部表示。

尝试一下 - DataSet 有很多糟糕的功能需要以 XML 形式表示（更改信息等），但这与设计合理的 API（Web 服务就是）完全无关。

尝试一下 - 在过去 10 年中，我所知道的任何项目都没有我认为是初级的人在任何地方都有数据集，无论 WCF 与否。大多数有知识的人在很多年前就转向了 OR 映射器。

【讨论】：

我会说我同意你的前 2 点，但最后一点不是一个可靠的论点，“它不是因为 每个人 都这样做 X”。说技术的进步和方法的变化就像世界上任何事情一样：D DataSet 在 .NET 1.x-2.0 中得到了发展，然后，.NET 和 OR/M 框架变得成熟，DataSet 成为了一个过时的解决方案并且完全是矫枉过正。就像 arrays 一样，这是必需的，但现在 .NET 解决方案更多地依赖于集合，因为它们具有有趣的特性：D
我在 .NET 之前 1 年前使用了 OR 映射器。我为 .NET 1.0 编写了一个。抱歉 - .NET 世界中 70% 的开发人员的无知是一个谬论。当 .nET 1.0 出现时，ORM 是一项成熟的技术。
你误解了我的话。 OR/M 是一种成熟的方法，因为 Hibernate 和其他人在其他人的 Java 中处于基础。而且，在我的例子中，我开发了一个基于属性的 OR/M 映射器，比如 Fluent NHib，它的一些特性也适用于 .NET 1.x，因为现有的 .NET 的 OR/M 框架都不是绝对成熟、稳定且它们没有像现在这样好的社区。span>
在最初的 .NET 时刻，WinForms 和 ASP.NET 控件对 DataSet 非常友好，而使用纯对象集合则更像是一项“自定义任务”。就是这样。
是的。像往常一样 - 正确的编程是一项任务，而不是一些拖放。

【解决方案4】：

使用无类型数据集，您无法真正塑造您传递给客户端的数据，包括您的表示层。对于内部 api，这不是什么大问题，但是如果您计划扩展您的 api 使用，您应该考虑使用静态类型模型而不是广泛的数据容器的好处。这对输入和输出都很重要。使用类型化模型，您可以更好地定义数据的预期形状及其行为，并且使用共享合同，您可以利用共享验证模型。

【讨论】：