将 ice/ace:dataTable 与 JPA 和请求范围的 bean 集成答案

【问题标题】：Integrating ice/ace:dataTable with JPA and request-scoped beans将 ice/ace:dataTable 与 JPA 和请求范围的 bean 集成
【发布时间】：2012-03-06 08:17:35
【问题描述】：

我想知道在 Hibernate/JPA 世界中处理数据表的正确方法是什么。据我所知，以下三个选择之一是导致整个纸牌屋分崩离析，但我不知道哪个是错误的。

半自动事务和 EntityManager 处理通过自定义 JSF PhaseListener 开始并围绕每个请求提交事务
将编辑组件放入数据表中
使用请求范围的托管 bean，从请求范围的 EntityManager 获取数据（在 PrettyFaces 的帮助下，通过其 URL 设置请求范围的 bean 的 ID）
使用请求范围的 bean 而不是视图或会话范围的 bean 支持 dataTable。

我看到an ICEfaces dataTable demo using JPA，但他们都是手动管理事务，默认情况下不显示编辑组件。您单击导致对象被提名为可编辑的行，然后当您点击“保存”时，它会在手动触发保存之前手动将对象重新连接到新的 EntityManager。我认为这里的点击编辑功能为我们提供了一种方法来确保将正确的对象重新附加到当前会话，我不知道如果没有类似的东西将如何生活。

我对新的 ICEfaces 3.0 ace:dataTable (née PrimeFaces 2.0 dataTable) 的印象是，它旨在用于视图或会话范围的 bean，但我不明白怎么能如果一个模型对象从请求 A 和 EntityManager A 中的 DAO 出来，然后被请求 B 和 EntityManager B 修改或分页，则绕过 StaleObjectState 和/或 LazyInitializationExceptions。

我想它可能在 Java EE 下通过某种深度 fu 工作，但我现在没有将我们从 Tomcat 6 升级到更高级的东西的奢侈（尽管从长远来看这是我的意图）。我们也不打算开始使用 Spring 或 Seam 或任何其他很酷的东西。 ICEfaces 对我们来说已经够奇怪了，说实话可能太奇怪了。

所以总结一下，以下哪个是错误的选择？请求范围的实体管理器、请求范围的数据表或在数据表中使用编辑组件？还是这里真的有其他问题？

【问题讨论】：

标签： jsf-2 icefaces-2

【解决方案1】：

如果您要问我，主要的错误似乎是坚持使用几乎裸露的 Tomcat，而您的要求似乎要求更高级的东西。口头禅通常是当你不需要“所有其他东西”时使用 Tomcat，所以当你确实需要它时，为什么还要继续使用裸 Tomcat？

也就是说，这个模式真的没那么难。

有一个视图范围的后备bean
在@PostConstruct-（当没有ID等参数时）或PreRenderViewEvent方法结合视图参数获取初始数据
使用单独的 Service 类，该类使用实体管理器来获取和保存数据
将实体管理器设为“事务范围”
- 没有 EJB/CDI/Spring：
  - 为每个操作从实体管理器工厂获取一个新的实体管理器。
  - 启动（资源本地）事务，执行操作，提交事务，关闭实体管理器。
直接从您的支持 bean 返回实体列表，将表的编辑模式输入字段绑定到实体的相应属性。
更新单行时，将相应的实体传递给服务的更新方法。除了获取实体管理器、启动事务等的开销外，这基本上只在实体管理器上调用merge()。

意识到您一直在使用detached entities 的服务之外。因此没有任何 LazyInitializationExceptions 的风险。支持 bean 需要在视图范围内，以便正确的（分离的！）实体由 JSF 更新，然后您自己的代码将其传递给服务，该服务将其合并到持久性上下文中。

因此，持久化的流程是：

查看状态 查看范围 事务范围PC Facelet/组件 Backing Bean 服务字符串 ------> 分离实体 --> 附加实体

（获取数据的流程正好相反）

以这种方式创建服务有点乏味，而且是一种自虐练习。对于一个示例应用程序和上面讨论的两种方法（get 和 update），它不会那么糟糕，但对于任何大型应用程序，这将很快失控。

如果您已经将 JSF 和 JPA 添加到 Tomcat，请帮自己一个忙，使用 TomEE 之类的东西。它只比 Tomcat 大一点（25MB 对 7MB），并且包含了所有你想避免但实际上仍然需要的东西。

如果您绝对无法升级您的 Tomcat 安装（例如，产品所有者或经理认为他拥有服务器而不是开发人员），您可能需要投资学习 CDI。这可以很容易地添加到您的战争中（只需一个额外的 jar），让您抽象出许多繁琐的代码。您还可以真正使用的一件事是 JTA 提供程序。这也可以单独添加到您的战争中，但是添加的东西越多，仅使用 TomEE（或 GlassFish、Resin、JBoss 等替代品）就越好。

另请参阅这篇文章，其中涵盖了您要求的各个部分：Communication in JSF 2.0

【讨论】：

感谢您的详细回答。如果我有我的 druthers，我们将升级到 Glassfish；我已经让我们的一些应用程序在它下成功加载，但还没有在 TomEE 下实际运行任何东西。我完全同意你对情况的分析，我只是没有这个时候强迫组织做我想做的事情的奢侈。不过，我认为我将能够应用您的建议并找到前进的道路。再次感谢！
@DanielLyons 为了我们的利益（我在 TomEE 工作），您能否详细介绍一下您在 dev(at)openejb.apache.org 上遇到的 TomEE 问题。我们是一个年轻的服务器，我们确实需要我们能得到的所有反馈。
本周晚些时候我会写信告诉你详细信息。我认为困难是由于它是一个测试版。
PrimeFaces MovieCollector 有一个基于 JPA 的 LazyDataModel。