实体，服务类和命令对象的最佳实践问题

Question

实体是直接映射到我们的数据库（我们用于Hibernate）的类。

在调用DAO之前，我们的服务类包含这些实体的业务逻辑。

我们还有命令对象，它们是与特定视图相关的POJO。我被告知实体本身不应该被用作命令对象，但我给出的“为什么”的答案是不够的。我希望有人能给我答案。

我们的一些观点非常简单。他们没有比实体本身更多的属性。将实体映射到命令对象似乎毫无意义，命令对象基本上是实体的镜像。

Answer 1

我认为在应用程序的所有层（控制器，视图，服务类和DAO层）中重用域模型对象（您称之为实体）没有问题。这是您经常看到的常见设计。

这个没有问题，当且仅当你有一个真正的图层分离 - 控制器从服务层获取模型对象时，服务层从DAO层获取模型对象等等。

如果您的设计通过从视图层调用Employee从数据库加载manager.getEmployees()个对象，那么这将无效。

Answer 2

似乎对象的命名可能存在一些混淆。命令对象通常提供单个execute（）方法（带有参数），该方法对给定实体或域对象进行操作，以根据业务逻辑改变其状态。这是将业务逻辑封装到简单对象中的一种非常巧妙的方式，这些对象的范围非常有限，无法改变其他对象。

然后，您正在使用的设计实际上会在数据传输对象（DTO或实体）和值对象（系统中的VO或Command对象）之间执行某种桥接。这可能非常浪费，因为您所做的只是将相同的数据复制到不同的对象中。

作用于数据传输对象（DTO或实体）模式的数据访问对象（DAO）已经很好地建立并促进了层之间的良好分离。通常，Hibernate会将实体映射到数据库，并懒惰地在其中加载集合。这是大多数设计绊倒的地方，因为它们不允许正确初始化集合，因为一旦执行线程离开DAO，会话就会消失。我认为JSP中的“Command对象”实际上是实体的子集，其中各种集合已经通过Hibernate查询初始化。

我建议您放弃“Command对象”，转而使用适当初始化的实体，这样可以在一个方面简化您的设计，但可以在另一个方面打开您的潜在问题。您需要仔细控制JSP如何引用和初始化集合。您可能会发现自己必须查看Open Session In View模式，以确保当JSP在某些尚未初始化的DTO上调用getCollection（）方法时，Hibernate Session对象可用。