如何将实体 Bean 转换为值对象？答案

【问题标题】：How to convert Entity Bean to Value Object?如何将实体 Bean 转换为值对象？
【发布时间】：2011-06-17 07:00:39
【问题描述】：

我正在开发一个为客户端和浏览器提供服务的服务器系统，我决定使用 JPA 处理数据库存储的 OR/Mapping。这导致实体 Bean 类暴露给客户端，因此我尝试通过使用值对象和数据传输对象来避免这种设计。这意味着我需要 POJO，以及在不同系统轮胎上交换 POJO 和实体 Bean 类的机制。

我的问题是，是否有任何成熟的设计模式或 EJB 指定的服务可以自动做到这一点？我真的很讨厌设计一些难以解耦和更新的 POJO - Entity Bean 一对一映射。

提前致谢

【问题讨论】：

标签： java jakarta-ee ejb-3.0

【解决方案1】：

这会导致实体 Bean 类暴露给客户，因此我尝试通过使用值对象和数据传输对象来避免这种设计。

为什么？是什么问题证明了如此严重的代码重复是合理的？

“数据传输对象”和错误使用“值对象”名称是 EJB 2 实体 Bean 避免过多服务器往返所必需的反模式。

如果您使用 JPA，则您没有实体 bean。您的实体是 POJO，将它们暴露给客户端绝对没有错 - 事实上，这是 JPA 最好的事情之一。

【讨论】：

是的，我不得不承认我提出了一个非常糟糕的问题。我是 EJB 的新手。感谢您的信息。
因为视图不必知道它所基于的每个实体或数据库表。因此，如果您更改持久性方法，则不必重写用户界面。与使用 O/R 映射抽象数据库调用的原因相同。
@BillR：当然你的视图必须知道它所基于的实体，否则它什么也做不了。而且视图不会不小心使用反射来访问 JPA 注释并依赖它们。有趣的是，您应该提到 O/R 映射——这就是 JPA。因此，“更改数据库中间项目”的案例已经涵盖了——尽管这从未真正发生过，当然也不是使用 OR 映射器的主要原因。它们用于避免编写大量重复的 CRUD 代码。
@Michael Borgwardt 我认为这是一种幼稚的观点，会导致未来（比如 10 年或更长时间）维护应用程序出现问题。这就是使用外墙等的原因。所以视图不需要知道数据库，所以在使用多个表的情况下减少远程调用的次数，视图也不需要知道数据库和实体很多的业务逻辑更接近。如果您所做的只是微不足道的单服务器应用程序，几乎没有业务逻辑，那么您的方式可能会奏效。对于任何重要的业务应用程序，我认为这是错误的。问候。
@BillR：我认为你误解了我的意思。我不建议直接从持久层获取这些 JPA 实体。当然应该有一个适当粒度的服务层。但是该服务层返回包含这些 JPA 实体的对象图是完全可以的。创建一个实体映射到的完整重复模型只是为了避免 JPA 注释在持久层之外可见，这是 YAGNI 的一个糟糕案例，并且会导致它自己的一组非常严重的维护问题。

【解决方案2】：

您可能想查看Dozer，这是一个使用反射根据字段名称映射bean 的bean 映射器。它为您提供了一些防止更改的保护，因为如果一个类发生更改但您希望保持映射的类保持不变，您始终可以手动指定映射。

【讨论】：

感谢您的帮助，artbristol，我现在正在学习推土机，看看它是否适合我的需要。同时，我正在考虑使用 JavaCompiler 和 Reflection 来动态完成所有工作:)