我发了几个问题，但还没有得到任何答复。我在这里陈述的一切都与JSF 2.0相关。*主要是。
典型的bean包含要在页面上显示的信息。基于Web的通用业务应用程序是一组页面，其中每个页面都包含由多个xhtml页面表示的视图编辑保存状态。所以我们创建一个bean来管理这些状态。但是我将在稍后描述几个问题：
1）每个页面都是不同的视图，因此迫使您将bean放入会话范围。它会使会话存储膨胀 2）在视图之间传递参数。为了编辑文档，应该知道文档的ID或/和另一组对象。将它们放入会话中并不是一个好的决定（膨胀的会话反模式）。
到目前为止，已经尝试了多次纠正这种情况的尝试。
a） t：saveState 。多年来它一直在发挥作用。但现在我们正在摆脱它。
b） Seam对话。在谈话结束的确切时刻，它已经施加了很多问题。超时不是一个容易设置的参数，因为我们不知道业务用户需要多长时间，例如，编辑文档。对我们来说不是解决方案
c） CODI（未尝试过）这似乎是一个很好的JSR 299实现，并且可以解决所有问题，但它几乎没有文件记录，并且，因为作为扩展，坚持WELD，这是另一个框架，我们只想使用JSF的所有功能。
d） Spring Web流程。嗯，这是一个非常好的框架，大量记录，伟大的IOC容器，流量范围和它提供的所有其他好东西可以是一种补救措施。它解决了乘法选项卡问题（这是我的措辞，所以请原谅我，如果不清楚我得到了什么）。想象一下，我们有一个编辑页面和视图范围的bean，我们正在填写表单。如果用户在新选项卡中打开另一个页面，则会触发GET请求并且bean超出范围。 Web流可以识别这样的问题，并在打开新选项卡时启动新流程。
（Web流程的延续）但它是单一的，并将迫使我们重写整个项目。是的，我知道它支持JSF，我已经测试过了一段时间，看看它是否符合要求。它不是因为它的安全性。不幸的是，我们没有时间也没有资源从头开始构建新项目。
我们几乎没有解决方案。 JSF是一个很好的框架，已经过广泛测试并在许多项目中使用。但是开发人员拒绝在其中加入CDI。
任何人都可以推荐使用单个bean编辑视图保存问题的任何解决方案吗？任何建筑建议都会有很大的帮助。非常感谢你。
答案 0 :(得分：5)
首先：这是一个讨论而不是一个问题，所以永远不会有一个明确的'是'或'不'......除了客观论点之外总有利有弊（开发者不喜欢它）; - ）
无论如何，让我首先确定您的情况对于所有类型的Web应用程序都非常常见，并且您所描述的问题对于从架构角度考虑Web应用程序开发的每个人来说更为常见。
在一年前遇到几乎完全相同的情况，这是我们的架构：
带有JSF 2.0的Java EE 6，CDI（+ EJB 3＆amp; JPA，但这超出了本答案的范围）。
所有这些都像魅力一样，层之间几乎没有胶水代码。
1）因此，每个页面都是不同的视图 强迫你把豆子放进去 会话范围。这需要付出代价 膨胀会话存储。
2）在视图之间传递参数。 为了编辑文档，应该 知道文件的ID或/和另一个 一组对象。将它们放入 会议不是一个好的决定 （臃肿的会话反模式）。
我绝对和你在一起。这就是我们使用对话的原因。
b）接缝谈话。它强加了 关于确切的问题很多 谈话结束的那一刻。超时 不是一个容易设置的参数 因为我们不知道多久了 例如，商业用户将是 编辑文档。不是解决方案 我们。
在Seam 2/3生产方面有3年的经验，我向你保证，这绝对是可以管理的。谈话适合像手套一样使用，过了一段时间你不想再使用其他任何东西了。当然不是会议; - ）
c）CODI（未尝试过）似乎是一个 不错的JSR 299实现， 可以解决所有问题 但它几乎没有记录， 因为是一个延伸，坚持 WELD是另一个框架 我们只是想利用所有的力量 JSF。
如果你想使用CODI，你不需要Weld，两者都是JSR 299实现。在撰写本文时，Weld更好地记录并更频繁地使用。我甚至不知道CODI是否是最终的？
d）Spring Web流程。嗯，这是非常的 很好的框架，大量记录， 伟大的IOC容器，流量范围和 它提供的所有其他好东西都可以 是一种补救措施。它解决了多重制表符 问题（这是我的措辞，所以原谅 我，如果不清楚我得到了什么 在）。想象一下，我们有一个编辑页面和 查看scoped bean，我们正在填充 表格。如果用户打开另一页 在新标签中，GET请求被触发 豆子超出了范围。网络流量 能识别出这样的问题 如果有新选项卡，则启动新流程 被打开了。
多标签问题也由Seam / Weld / CODI解决。那是九十年代......
我们几乎没有解决方案。 JSF是一个很棒的框架，一直都是 广泛测试并在许多中使用 项目。但开发商拒绝 包括CDI。
JSF的问题在于您的项目不是绿地。您需要连接到后端，而在使用纯JSF范围和技术时会遇到问题。
我只能告诉你：我也必须说服我的同事使用CDI。我用所描述的布局中的工作原型做到了，现在，一年后，团队中的每个人都对我们的技术堆栈非常满意...... :-)
总结这个相当冗长的答案：
Java EE 6是适用于此类应用程序的优秀技术堆栈，您应该尝试一下。您描述的问题不仅仅是使用Java EE 6 solvable ，而是在设计API时，它们是规范团队想到的问题。
如果您愿意，请随意发表更多疑问/疑问。
答案 1 :(得分：1)
只是一般性说明：
OpenWebBeans ，焊接和 CanDI 是 JSR-299实施，因此真正的容器提供了管理上下文实例，上下文，事件等。
CODI 是一个可移植的 JSR-299扩展程序（如 Seam3 ），可以在任何CDI容器上运行。您可以在上面提到的所有CDI容器上使用CODI。
CODI基本上提供了一些不同的东西：
1。）一个核心模块，其中包含有用的东西，如@ProjectStageActivated（基于JSF ProjectStage启用/禁用bean），可注入消息，
2.。）JSF支持模块，包含许多额外的范围，如@ ViewAccessScoped，@ WindowScoped（每个窗口的bean），@ ConversationGroup，类型安全的@View导航，CDI @PhaseListener等等
3。）JPA @Transactional支持。这将为您提供轻松的持久性，而无需使用EJB