因此,经典的 Web 应用程序架构。控制器、服务、映射器(将 dto 映射到实体并返回)。在某些层中,您需要自动装配映射器并将 dto 转换为实体并返回。有两种方法。
控制器中的转换。因此,服务已经接受了一个具有所有依赖关系的实体并返回一个实体(它再次在控制器中转换为 dto 并发送到前面)。这种做法的背后是考虑到 dto 是从外部接收的数据,这意味着它必须尽早转换为实体,并以实体的形式进入其他层。此外,当我们需要在服务 B 中获取实体 A 时,这种方法也得到了支持。然后在服务 B 中,我们自动装配服务 A,通过实体 ID 转到服务 A 并获取实体,但服务返回 dto,现在它将接收到的 dto 中的实体转换为返回到服务 B 的实体,并在那里将 dto 反向转换为实体,填充依赖项并前往基础。还是我们必须编写第二种方法
public Car get(Long id)除了public CarDto get(Long id). 这也没有简化代码。服务转型。这种方法涉及仅使用实体来处理存储库。该方法的优点是dto在依赖方面比实体轻得多,并且在服务之间驱动它更容易,并且使用dto更容易。无需考虑使用实体的数据一致性、延迟初始化和其他微妙之处。此外,它允许您控制对数据库的所有请求,如果我们需要依赖项,我们只需根据 dto 数据获取它,从而避免了为了获取 int 字段而必须拉整个实体的情况数据库中的依赖树并将其存储在内存中。
所以,先生们,我想听听你们对此的看法。
我认为最好与所有层分开转换:在层外的转换器中。并且在控制器中绝对不会调用转换。这是一个很好的英文图表