数据传输对象DTO在何处构建

Question

试图重构一些代码.我看到一些创建DTO对象的类正在服务层中传递,后来由@RestController返回.据我所知,最好只在控制器中构建数据传输对象并将它们传递给视图,尤其是当我们使用WrapperDTO<T>get和set值之类的东西时.当我们使用复杂对象或简单数据类型构建WrapperDTO时,可能存在差异.所有的oppinions将非常感激.

Answer 1

DTO可用于在应用程序的不同层之间传输数据:DAO,服务,外观,控制器.根据我的经验,DTO是一个自以为是的主题.

在我看来,转换越晚越好,如果不需要转换则更好.通常,后者位于应用程序边界.DTO不是免费的,它涉及映射及其支持.因此,当存在域模型不匹配或模型技术不匹配时,DTO将是有意义的.有关更多信息,您可以查看LocalDTO文章和相关链接.

如果我专注于服务 - > facade - > 控制器层:

• 服务:他们正在做服务,他们可能会互相打电话进行处理.如果您的域模型在服务边界内保持一致,那么service => facade将结果转换为DTO为时尚早.

• Facades:他们可以协调服务并转换输入/输出.在我看来,它将是转换到DTO或从DTO转换的正确位置.但只有在需要时才是这样.因为你的域模型必须在这个边界上进行转换(过滤字段,聚合......)

• 网关/控制器:它们位于应用程序边界.他们的逻辑很简单,简化为边界逻辑.外观和控制器之间的关系通常是one <-> one.***

  合并外墙和控制器通常是有道理的

因此,在我看来,你的第一个提案更适合,例如.UserController.....最重要的是保持务实.

Answer 2

我想说最好在服务层创建DTO。

控制器必须不知道业务逻辑细节。例如，我们需要返回用户信息，但必须排除某些字段（密码等）。这些字段存在于用户实体中，但必须从 DTO 中删除。

我们SomePaginationDTO在 Controller 上遇到的另一种情况是，我们仍然需要将 DTO 传递给服务来解析过滤器、应用排序、限制结果等。所有逻辑都是服务职责的一部分。所以我会把它传递SomePaginationDTO给服务。