1

对于开发 REST Web 服务，有 5 个基本用例（如我所见）

/api/entities        - GET
/api/entities/{id}   - GET
/api/entities        - POST
/api/entities/{id}   - PUT
/api/entities/{id}   - DELETE

DTO 提供了与 Web 服务交互所需的数据的最佳表示。

我喜欢这两个概念，但我苦苦挣扎的是如何组织 DTO 与它们如何与特定 Web 服务交互。

每个 Web 服务是否应该只有一个 DTO？例子：

EntityDto
    - Property1
    - Property2
    - Property3
    - Property4
    - Property5

还是每个用例都应该有一个 DTO？例子：

GetEntityDto 
   - Property1
   - Property2
   - Property3
   - Property4
   - Property5

AddEntityDto
   - Property2
   - Property3
   - Property4
   - Property5

EditEntityDto
   - Property4
   - Property5

如果您只能更新 2 个属性，我认为为什么要发送所有 5 个？

处理与 REST Web 服务相关的 DTO 的最佳方法是什么？

4

3 回答 3

0

我想我会问自己的问题是：我是否想针对网络带宽优化我的 API 并将其耦合到 HTTP 方法，或者我是否想将我的 API 公开为一个简单的模型以允许消费者（当前和未来）更大他们如何实现对 API 的使用的自由度？

于 2013-04-16T12:57:59.213 回答
0

我几乎总是根据需要开发 DTO。使用 .NET 匿名类型和/或 AutoMapper 等映射实用程序可以轻松完成。DTO 与 UI 高度耦合，您几乎无法通过预先设计它们来优化您的开发，而无需确切知道您的 UI 会是什么样子。唯一的例外是删除，您只需要 ID。

于 2013-04-16T16:06:39.757 回答
0

您是对的 您可以创建针对视图自定义的 DTO，例如查询将仅显示在列表中的实体列表只能具有名称、ID 和图像，但详细信息页面可能需要包含更多的 DTO来自同一实体的属性。DTO 取决于您的端点和动词。在一对多或多对多关系的情况下，POST 可能要求您发送甚至可能不在实体中的数据，例如类别 ID。通常在多对多关系的情况下，您会在返回数据时省略链接以避免递归/循环引用。

于 2022-02-17T10:14:16.100 回答