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