我想知道处理在Hibernate / JPA世界中输入的dataTable的正确方法是什么。据我所知，以下三种选择中的一种导致整个纸牌屋分崩离析，但我不知道哪一个是错的。
我看到an ICEfaces dataTable demo using JPA但他们都是手动管理交易而不是默认显示编辑组件。单击导致对象被指定可编辑性的行，然后当您点击“保存”时，它会手动将对象重新连接到新的EntityManager，然后再手动触发保存。我在这里看到了点击编辑功能，为我们提供了一种确保正确的对象重新连接到当前会话的方法，而且我不知道没有类似的东西会如何生活。
我对新的ICEfaces 3.0 ace的印象：dataTable（néePrimeFaces2.0 dataTable）是打算在View或Session-scoped bean中使用，但我不知道怎么可能如果有一个模型对象来自请求A和EntityManager A中的DAO，然后被请求B使用EntityManager B进行修改或分页，则可以解决StaleObjectState和/或LazyInitializationExceptions。
我认为它可以通过某种深层次的功能在Java EE下工作，但是我没有把我们从Tomcat 6升级到任何更高级的东西（尽管从长远来看这是我的意图）。我们也不打算开始使用Spring或Seam或其他很酷的东西。 ICEfaces对我们来说太奇怪了，老实说可能太奇怪了。
总结一下，哪一个是错误的选择？请求范围的实体管理器，请求范围的dataTable或在dataTable中使用编辑组件？或者其他地方真的有问题吗？
答案 0 :(得分：4)
如果你问我，当你的要求似乎为一些有点发烧友的东西尖叫时，主要的错误似乎是坚持几乎裸露的Tomcat。通常情况下，当你不需要“所有那些其他东西”时你使用Tomcat，所以当你需要它时，为什么要继续使用一个裸Tomcat？
那就是说，这种模式并不那么困难。
@PostConstruct中的初始数据 - （当没有像ID这样的参数时）或PreRenderViewEvent方法结合视图参数merge()。了解您在服务之外始终与detached entities合作。因此，任何LazyInitializationExceptions都没有风险。支持bean需要在视图范围内，以便JSF更新正确的（分离的！）实体，然后您自己的代码将其传递给服务，该服务将其合并到持久性上下文中。
坚持的流程是：
View state View scope Transaction scoped PC
Facelet/components Backing Bean Service
Strings ------> Detached entities --> Attached entities
（获取数据的流程正好相反）
以这种方式创建服务虽然有点乏味，但却是一种受虐狂的练习。对于一个示例应用程序和上面讨论的两种方法（获取和更新），它不会那么糟糕，但对于任何大小的应用程序，这将很快失控。
如果您已经将JSF和JPA添加到Tomcat，那么请帮自己一个忙，并使用类似TomEE的内容。这几乎不比Tomcat大（25MB对7MB）并包含你应该避免的所有东西，但实际上还是需要它。
如果你绝对无法升级你的Tomcat安装（例如产品所有者或经理认为他拥有服务器而不是开发人员），你可能想投资学习CDI。这可以很容易地添加到你的战争（只是一个额外的jar），让你抽象出许多繁琐的代码。你也可以真正使用的一件事是JTA提供商。这也可以单独添加到你的战争中，但你添加的东西越多，你就会越好，只需使用TomEE（或GlassFish，Resin，JBoss等替代品）。
另请参阅此文章，其中涵盖了您的要求的各个部分：Communication in JSF 2.0