JSF 2.0 - bean 范围的可能性

Question

我发布了几个问题，但尚未得到任何答复。我在这里陈述的所有内容都主要涉及 JSF 2.0.*。

一个典型的 bean 包含要在页面上显示的信息。常见的基于 Web 的业务应用程序是一组页面，其中每个页面都涉及查看-编辑-保存状态，这些状态由多个 xhtml 页面表示。所以我们创建了一个 bean 来管理这些状态。但是有几个问题我将很快描述：

1) 每个页面都是不同的视图，因此迫使您将 bean 放入会话范围。这会导致会话存储膨胀。
2) 在视图之间传递参数。为了编辑文档，应该知道文档或/和另一组对象的 ID。将它们放入会话不是一个好的决定（臃肿的会话反模式）。

到目前为止，已经尝试了几次纠正这种情况的尝试。

a) t:saveState。它多年来一直在做它的工作。但现在我们正在摆脱它。 b) 无缝对话。它在对话结束的确切时刻带来了很多问题。超时不是一个容易设置的参数，因为我们不知道业务用户将编辑文档多长时间。不是我们的解决方案。
c) CODI（未尝试） 这似乎是一个不错的 JSR 299 实现，并且可能会解决所有问题，但它几乎没有文档记录，并且由于是扩展，因此坚持使用 WELD，即另一个框架，我们只想使用 JSF 的所有力量。
d) Spring 网络流。嗯，它是一个非常好的框架，有大量的文档，很棒的 IOC 容器、流范围和它提供的所有其他好东西都可以作为补救措施。它解决了多标签问题（这是我的措辞，如果不清楚我的意思，请原谅我）。想象一下，我们有一个编辑页面并查看范围 bean，我们正在填写表单。如果用户在新选项卡中打开另一个页面，则会触发 GET 请求并且 bean 超出范围。 Web 流可以识别此类问题并在打开新选项卡时启动新流。

（继续Web Flow）但它是单片的，将迫使我们重写整个项目。是的，我知道它支持 JSF，我已经测试并摸索了一段时间，看看它是否符合要求。这不是因为它的安全性。不幸的是，我们没有时间和资源从头开始构建一个新项目。

我们的解决方案几乎用完了。 JSF 是一个很棒的框架，已经过广泛的测试并在许多项目中使用。但开发人员拒绝在其中包含 CDI。

任何人都可以推荐任何解决方案来解决单个 bean 的编辑-视图-保存问题吗？任何架构建议都会有很大帮助。非常感谢您。

Answer 1

首先：这与其说是一个问题，不如说是一个讨论，所以永远不会有一个明确的“是”或“不是”......除了客观的论点之外，总会有利弊（开发人员不喜欢它) ;-)

无论如何，让我首先确定您的情况对于所有类型的 Web 应用程序都很常见，而您所描述的问题对于从架构角度考虑 Web 应用程序开发的每个人来说都更为常见。

一年多前面临几乎相同的场景，这是我们的架构：

带有 JSF 2.0、CDI 的 Java EE 6（+ EJB 3 和 JPA，但这超出了此答案的范围）。

• ViewScoped Bean，每个视图一个（JSF ViewScope 使用 Seam 3 Faces 连接到 CDI）
• ConversationScoped SFSB 作为门面每个用例 用于业务逻辑、事务/安全边界（门面被 1 - n 视图控制器引用）
• RequestScoped 服务（无状态，可被其他客户端重用（通过不同的门面）

这一切都像一个魅力，层之间几乎没有胶水代码。

1) 每个页面都是不同的视图，因此 强迫你将 bean 放入 会话范围。它需要付出代价 使会话存储膨胀。

2) 在视图之间传递参数。 为了编辑文档，您应该 知道文件的 ID 或/和另一个 对象集。将它们放入一个 会议不是一个好的决定 （臃肿的会话反模式）。

我绝对支持你。这就是我们使用对话的原因。

b) 接缝对话。它强加了 这么多关于精确的问题 谈话结束的那一刻。暂停 不是一个容易设置的参数 因为我们不知道多久 例如，业务用户将是 编辑文档。不是解决方案 我们。

凭借 Seam 2 / 3 的 3 年生产经验，我向您保证，这绝对是可以管理的。对话适合像手套一样的用例，一段时间后你不想再使用其他任何东西。当然不是会话;-)

c) CODI(未尝试) 这似乎是一个 不错的 JSR 299 实现，并且， potentily可以解决所有问题 但它几乎没有记录，而且， 由于是扩展，坚持 WELD 是另一个框架 我们只想使用所有的力量 JSF 的。

如果您想使用 CODI，则不需要 Weld，两者都是 JSR 299 实现。在撰写本文时，Weld 的文档记录更好，使用频率更高。我什至不知道CODI是否是最终的？

d) Spring 网络流。嗯，这是一个非常 不错的框架，文档丰富， 出色的 IOC 容器、流量范围和 它提供的所有其他好东西都可以 成为一种补救措施。它解决了乘法选项卡 问题（这是我的措辞，请原谅 如果不清楚我得到了什么 在）。假设我们有一个编辑页面，并且 查看作用域bean，我们正在填充 表格。如果用户打开另一个页面 在新选项卡中，触发 GET 请求并 bean 超出范围。网络流 能认识到这样的问题并 如果新选项卡有，则启动新流程 已打开。

Seam / Weld / CODI 也解决了多选项卡问题。真是九十年代了……

我们的解决方案几乎用完了。 JSF 是一个很棒的框架，一直 经过广泛测试并用于许多 项目。但开发商拒绝 在其中包含 CDI。

JSF 的问题在于您的项目不是新建项目。您需要连接到后端，而使用纯 JSF 作用域和技术将遇到问题。

我只能告诉你：我也必须说服我的同事使用 CDI。我在描述的布局中使用了一个工作原型，现在，一年后，团队中的每个人都对我们的技术堆栈非常满意...... :-)

总结这个相当冗长的答案：

Java EE 6 是用于此类应用程序的绝佳技术堆栈，您应该尝试一下。您所描述的问题不仅可以通过 Java EE 6 解决，而是规范团队在设计 API 时考虑的问题。

如果您愿意，请随时发布更多问题/疑问。

Answer 2

只是一般说明：

OpenWebBeans、Weld 和 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 即可轻松持久化