时间戳

首页 > 解决方案 > 准备响应主体的逻辑应该在@Service 上还是@Controller 上？

java - 准备响应主体的逻辑应该在@Service 上还是@Controller 上？

问题描述

我正在使用Spring Boot，并将尝试解释出现我怀疑的情况。

想象一下，它MyObject有一些其他的对象组成。

public class MyObject {

    private Integer id;
    private MyObject2 obj2;
    private MyObject3 obj3;
    private MyObject4 obj4;

    // getters and setters ...

}

其中一些领域，已经MyObject组成了它们。

比方说MyObject2，MyObject作为一个领域，在双方之间建立某种关系。（例如：多对一）

public class MyObject2 {

    // other fields
    private List<MyObject> objs;

    // getters and setters

}

由于我正在使用 REST API 并且需要将此实体返回到 Json 中，因此在序列化时可能会发生无限递归，因为一个实体引用另一个实体。

当我解决创建 DTO 和辅助类的递归问题时，我对调用 DTO 和辅助类的逻辑应该去哪里存有疑问。

助手.java

public static MyObject buildPrettyMyObject(MyObject obj) {
    obj.setObj2(null);

    return obj;
}

防止无限递归的逻辑是通过设置来删除MyObject2引用上的所有MyObject引用。MyObject2null

我的 Helper 类完成了这项工作，但是，我应该在哪里调用它？

在我的控制器中：

public ResponseEntity<?> handleRequestOfRetrieveAllMyObject2() {
    List<MyObject2> objs2 = obj2Service.findAll();
    objs2.forEach(obj2 -> obj2.getObjs().forEach(obj -> Helper.buildPrettyMyObject(obj)));

    return ResponseEntity.ok(objs2);
}

在我的服务中：

public List<MyObject2> findAll() {
    List <MyObject2> objs2 = obj2Repository.findAll();
    objs2.forEach(obj2 -> obj2.getObjs().forEach(obj -> Helper.buildPrettyMyObject(obj)));

    return objs2;
}

应该是 Service 层的工作，还是 Controller 层的工作？

我在控制器层这样做，因为控制器负责将响应返回给客户端，而服务层应该只执行业务规则并且必须是可重用的。

我做错了吗？

标签： javarestspring-boot

解决方案

我在控制器层这样做，因为控制器负责将响应返回给客户端，而服务层应该只执行业务规则并且必须是可重用的。我做错了吗？

你做得对。这是一个表示/序列化问题，因此理想的候选者是控制器层。但这是您可以花费数天甚至数周时间讨论的自行车脱落问题之一。你做得对，继续前进。

推荐阅读