1

我开发了一个具有4 层的 Java 应用程序：数据库（MySQL）、持久性（JPA）、业务（类似于 EJB 中的无状态会话 bean 的 POJO）、表示（Java Swing）。

我决定完全解耦表示层和持久层。所以对所有数据的所有修改都是通过业务层完成的。这样，表示层甚至不知道实体类的存在。这也允许会话 bean 更好地控制传递的数据，因为有时会话 bean 需要在更改实体之前验证或转换从表示接收的值。

然而，有时会话 bean 需要向调用者发送大量信息（如具有大量属性的实体列表）。这变得复杂了，因为根据我采用的会话 bean 的设计，需要将所有这些实体解包到其他东西中。我试图将实体列表转换为数组列表（其中数组的每个成员对应于实体中的一个属性），但这对我来说似乎存在缺陷、容易出错且效率低下。

将数据发送到演示文稿的正确方法是什么？将实体隐藏在会话 bean 后面的概念是否有意义？此类应用程序中的常见模式是什么？

4

2 回答 2

2

常见的模式是在符合要求时使用 JPA 实体（即，当它们包含表示层所需的数据时，并且当您不需要获取数据库的一半来返回此数据时），并使用 DTO （数据传输对象，它们只是包含所需信息的 POJO）当实体不符合要求时。

有些人喜欢只使用 DTO，就像你正在做的那样。但是 DTO 应该是具有类型属性的真实对象。数组列表是难以理解和维护的噩梦，不提供任何类型的类型安全和编译检查，并且通常需要 JavaBeans 的经典表示层技术（JSP EL 等）不容易使用。

于 2012-06-19T11:08:25.217 回答
1

将实体隐藏在会话 bean 后面的概念是否有意义？此类应用程序中的常见模式是什么？

是的，如果客户端在不同的 JVM（远程）上运行，我建议发送 DTO（设计模式；数据传输对象）而不是 JPA 实体。

您可能正在寻找的 EJB 设计模式是： 服务外观 目标是提供粗粒度的、客户端/用例特定的 API。

Adam Bien 写了一本关于 Java EE 5/6 设计模式的书：http: //press.adam-bien.com/real-world-java-ee-patterns-rethinking-best-practices.htm

仅发送用户可以方便处理的尽可能多的数据，例如使用过滤或分页技术。

于 2012-06-19T11:05:43.250 回答