java - 业务层是否应该将持久化对象返回给UI层？

Question

假设我有一个 POJO 类 Meal 。该类使用 ORM(例如 JPA + Hibernate)进行映射，因此我可以将其保存在数据库中。除此之外，该类包含 List<Dish> dishes (Dish 是另一个映射的 POJO)由 ORM 延迟加载。

现在我有一个业务层方法Meal getNextDueMeal() 。这由 UI 层调用，然后向用户显示餐食。当然，组成餐点的菜肴也应该展示出来。

但是我该怎么处理这个问题呢？如果我尝试迭代 getMeals() 返回的列表天真地，我会得到一个 LazyInitializationException 。我可以维护 EntityManger在 UI 层，例如通过使用 Spring 的 @Transactional注解。但是，从业务逻辑返回的对象将保持持久性，即如果我以某种方式修改 Meal - UI 中的“POJO”，一旦我从@Transactional返回，它就会自动保存。 -方法，这可能不是我想要的。

tl;dr:业务层是否应该将持久对象返回给UI层？如果没有，我该如何处理延迟加载？

Answer 1

当您使用远程接口(interface)时，将实体作为业务层返回值返回并不是一个好主意。您可以定义一些DTO 或数据传输对象，并从获取的实体中填充它们，并将这些 DTO 作为返回值返回。

Should the business layer return persistent objects to the UI-Layer? And if not, how do I deal with lazy loading?

关于延迟加载，您可以将业务层中所有必需的值填充到 DTO 对象中，因此，在您的 UI 层中，所有必需的属性都已加载，并且您不会遇到那些LazyInitializationException异常。

它是如何工作的？

---

引用自PoEAA :

The fields in a Data Transfer Object are fairly simple, being primitives, simple classes like Strings and Dates, or other Data Transfer Objects. Any structure between data transfer objects should be a simple graph structure—normally a hierarchy—as opposed to the more complicated graph structures that you see in a Entity.

就您而言，您可能会有一个 MealDto 和一个 DishDto，如下所示:

public class MealDto {
    private String name;
    private List<DishDto> dishes;

    // getters and setters
}

您可以使用另一个抽象负责从相应的实体组装 DTO。例如，您可以使用 MealAssembler:

public class MealAssembler {
    public MealDto toDto(Meal meal) {
        MealDto dto = new MealDto();
        dto.setName(meal.getName);
        // populate the other stuff    

        return dto;
    }
}