时间戳

首页 > 解决方案 > DTO 的前缀模式

design-patterns - DTO 的前缀模式

问题描述

我有一些端点，它们有它们的 DTO。如今，DTO 的名字变得糟糕透顶。例如，服务：order/item/ean 我们的主要响应文件，被命名为：OrderItemEanResponseVo。所有子类都收到前缀 OrderItemEan。

但是，例如，我们在其中有一个实体 OrderItem。它的名字是：OrderItemEanOrderItemVo。

是的，太可怕了。

你知道命名 DTO 的任何模式吗？

标签： design-patterns

解决方案

正如您可能猜到的那样，没有一个单一的答案，但是当涉及到命名时，特别是在嵌套上下文中，我通常参考 Robert C. Martin 的 Clean Code Chapter 2, Don't Add Gratuitous Context：

“在一个名为“Gas Station Deluxe”的假想应用程序中，在每个班级前加上 GSD 是一个坏主意。坦率地说，你正在反对你的工具。你输入 G 并按下完成键，并获得一英里长的列表作为奖励系统中的每个班级。”

[...]

名称accountAddress和customerAddress是类实例的好名称，Address但可能是类的糟糕名称。 Address是一个类的好名字。如果我需要区分 MAC 地址、端口地址和 Web 地址，我可能会考虑 PostalAddress、MAC和URI.

使用有意义的上下文，但不要让您的命名成为您的域顶部的线索。这就是您的命名空间的用途。

例如，考虑一个MovieRepository用于检索电影的存储库的 get 方法。无意义的上下文将是给它一个方法GetMovie(int id)。相反，使用Get(int id). 这是足够的上下文，因为您的消费者很清楚他们正在使用的上下文。

我认为只有您和您的同事足够了解您的领域，才能确定需要多少上下文才能使其有意义，而不是浪费，但如果有必要使用 OrderItem 作为其嵌套成员的前缀以使其有意义，也许您需要考虑它们是否与您的业务领域密切相关，或者过于笼统？

推荐阅读