我开发了一个带有 4层的Java应用程序：数据库（MySQL），持久性（JPA），业务（POJO类似于EJB中的无状态会话bean），表示（Java Swing）。
我决定完全解耦演示文稿和持久层。因此，对所有数据的所有修改都是通过业务层完成的。这样，表示层甚至不知道存在实体类。这还允许会话bean更好地控制传递的数据，因为有时会话bean需要在更改实体之前验证或转换从演示文稿接收的值。
但是，有时会话bean需要向调用者发送大量信息（如具有大量属性的实体列表）。这变得很复杂，因为根据我采用的设计，会话bean需要将所有这些实体解包到其他东西中。我试图将实体列表转换为数组列表（其中数组的每个成员对应于实体中的属性），但这似乎是如此有缺陷，容易出错且效率低下我
将数据发送到演示文稿的正确方法是什么？隐藏会话bean后面的实体的概念是否有意义？这类申请中的常见模式是什么？
答案 0 :(得分：2)
常见的模式是在适合账单时使用JPA实体（即，当它们包含表示层所需的数据时，以及当您不需要获取数据库的一半来返回此数据时），以及当实体不适合账单时，使用DTO（数据传输对象，它们只是包含所需信息的POJO）。
有些人喜欢只使用DTO，就像你正在做的那样。但是DTO应该是具有类型属性的真实对象。数组列表是理解和维护的噩梦，不提供任何类型的安全性和编译检查，并且不易被传统的表示层技术（JSP EL等）使用，它们通常期望JavaBeans。
答案 1 :(得分：1)
隐藏会话bean后面的实体的概念是否有效 任何意义上的？这类申请中的常见模式是什么？
是的，如果客户端在不同的JVM（远程）上运行，我建议发送DTO（设计模式;数据传输对象）而不是JPA实体。
您可能正在寻找的EJB设计模式是：Service Facade 目标是提供粗粒度的客户端/用例特定API。
Adam Bien写了一本关于Java EE 5/6设计模式的书： http://press.adam-bien.com/real-world-java-ee-patterns-rethinking-best-practices.htm
只发送用户可以方便处理的数据，例如使用过滤或分页技术。