我正在做的一个项目有这种设计模式，jsp/action/service类定义和使用一个bean，即表示和业务逻辑层使用，同时定义另一个bean并且被DAO层使用，称为“实体”，无论这两个bean的内容实际上是相同的，我被告知使用两个bean是Java EE设计模式所要求的，以解耦每一层。我对解耦的理解是通过类的工作流以及类层次结构来实现的，但是对于数据流，使用相同的 bean 是直接而流畅的，而为 DAO 层引入 POJO 的原因之一是确保这种转变是顺利的。请分享您的专业知识，通过解耦这个数据流可以获得好处，以及在数据流中使用相同的 bean 会有什么缺点？
【问题讨论】：
标签： design-patterns jakarta-ee architecture domain-model
那些告诉你“Java EE 设计模式需要使用两个 bean”的人是错误的。如果您愿意，您可以这样做，有些人一直热衷于这样做，但从来没有必需。
（可能是他们在考虑 EJB3 之前的实体 bean，它不能暴露给表示层，所以需要某种到 DTO 的映射。但现在这已经过时了很长时间。甚至当时避免实体 bean 和使用 JDBC 很常见。）
Here's an article I like on using DTOs in layered applications.
我曾与强烈支持将单独的 bean 用于表示层的人交谈过，支持将实体映射到单独的表示层 bean 的最大担忧是持久对象上的方法在调用时会导致更改数据存储区，他们需要保证不能从表示层调用这些方法。对我来说，这意味着他们错过了使用POJOs 进行持久性的要点，即它们可以包含业务逻辑（即更改对象图状态的方法），但它们对基础架构没有任何依赖关系。 Gavin King 和公司遇到了很多麻烦，所以他们不必在持久实体上放置保存方法，然后他们在持久实体上放置保存方法，这样做需要大量工作来确保没有人会滥用原本不应该存在的方法。
【讨论】：
仅仅因为它很时髦或符合任何东西就使用你不需要的东西是没有意义的，但是让它在未来得到验证可能是值得的。
您实际上拥有的是领域模型（非实体 bean）和实体。当您处理复杂的域逻辑时，这是必须具备的，而不是将逻辑放在实体中，而是将其放在域逻辑 POJO 中，或者当您的数据相当复杂并且您实际上无法将 DM bean 直接映射到数据库，你需要多个实体来做到这一点。域模型也有助于继承。
现在，如果您的 bean 完全相同，那么您要么有一个非常简单的模型，要么您没有正确使用域模型，请自行选择，您知道那里有什么。
你应该看看Domain Model“模式”，例如在经典的“企业应用程序架构模式”的第 9 章中
【讨论】：
Java EE（现在不是 J2EE）建议使用 JPA 进行数据访问（替换实体 Bean），将 JPA 层包装在 Session EJB 外观上。我认为您的问题相当于决定了该外观中使用的类型，即DTO 传入和传出。这些 DTO 可以是 JPA bean 还是我们应该使用单独的类？
JPA bean 只是带注释的 POJO，因此它们可以合理地传递到 JSP/Servlet 层。在简单的情况下，这就是我看到的情况。随着业务逻辑变得更加有趣，我注意到有时我们需要更多以业务为中心的对象作为 DTO，所以是的，我将对象分开。
我的建议：根据对调用者的意义来设计会话 Bean 外观，如果发现 JPA 对象可以工作，则使用它们。
【讨论】：