JSF 2.0 - bean 范围的可能性
我发布了几个问题，但尚未得到任何答复。我在这里所说的一切主要涉及 JSF 2.0.*。
典型的 Bean 包含要在页面上显示的信息。常见的基于 Web 的业务应用程序是一组页面，其中每个页面都涉及查看-编辑-保存状态，并由多个 xhtml 页面表示。因此，我们创建一个 bean 来管理这些状态。但有几个问题我将很快描述：
1) 每个页面都是不同的视图，从而迫使您将 bean 放入会话范围。它会导致会话存储膨胀。
2) 在视图之间传递参数。为了编辑文档，人们应该知道文档的 ID 或/和另一组对象。将它们放入会话中并不是一个好的决定（臃肿的会话反模式）。
到目前为止，已经尝试了几次纠正这种情况的尝试。
a) t:saveState。多年来它一直在履行自己的职责。但现在我们正在摆脱它。 b) 接缝对话。它带来了很多关于谈话结束的确切时刻的问题。超时不是一个容易设置的参数，因为我们不知道业务用户将编辑文档等时间。这对我们来说不是解决方案。
c) CODI（未尝试） 这似乎是一个不错的 JSR 299 实现，并且有可能解决所有问题，但它很少有文档记录，并且由于是扩展，因此坚持使用 WELD另一个框架，我们只想使用 JSF 的所有功能。
d) Spring Web 流。嗯，这是一个非常好的框架，文档丰富，出色的 IOC 容器、流程范围以及它提供的所有其他好东西都可以作为补救措施。它解决了乘法选项卡问题（这是我的措辞，所以如果不清楚我的意思请原谅我）。假设我们有一个编辑页面和视图作用域 bean，并且我们正在填写表单。如果用户在新选项卡中打开另一个页面，则会触发 GET 请求并且 bean 超出范围。 Web 流可以识别此类问题，并在打开新选项卡时启动新流。
（Web Flow 的续集）但它是单一的，将迫使我们重写整个项目。是的，我知道它支持 JSF，并且我已经测试并摸索了一段时间，看看它是否符合要求。并不是因为它的安全性。不幸的是，我们没有时间也没有资源从头开始构建新项目。
我们几乎已经没有解决方案了。 JSF 是一个很棒的框架，已经过广泛的测试并在许多项目中使用。但开发商拒绝将CDI纳入其中。
任何人都可以推荐任何解决方案来解决单个 bean 的编辑-查看-保存问题吗？任何架构建议都会有很大帮助。预先非常感谢您。
I posted a couple of questions but haven't gotten any reply yet. Everything I state here concerns JSF 2.0.* mostly.
A typical bean contains information to be displayed on a page. Common business web-based application is a set of pages where each of them involves view-edit-save state which are represented by several xhtml pages. So we create a single bean to manage those states. But there are several problems I will describe shortly:
1) Each page is a different view thus forcing you to place bean into a session scope. It takes its toll in bloating the session storage.
2) Passing parameters between views. In order to edit a document one should know ID of the document or/and another set of objects. Placing them into a session is not a good decision (bloated session antipattern).
So far several attempts to rectify a situation have been tried.
a) t:saveState. It has been doing its job for many years. But now we are getting rid of it.
b) Seam conversation. It has imposed so many problems concerning an exact moment the conversation dies. Time out is not an easy parameter to be set since we don't know how long a business user will, for example, be editing a document. Not a solution for us.
c) CODI(not tried) It seems to be a nice JSR 299 implementation and, potentilly can solve all out problems but it is so scarcely documented and, since being an extension, sticks to the WELD which is another framework and we just want to use all the power of JSF.
d) Spring web flow. Well, it is a very nice framework, documented abundantly, great IOC container, flow scope and all other nice things it provides can be a remedy. It solves multiply tab problem(it is my wording, so forgive me if it is unclear what I am getting at). Imagine we have an edit page and view scoped bean and we are filling the form. If users opens another page in a new tab, GET request is fired and the bean goes out of scope. Web flow can recognise such a problem and starts a new flow if a new tab has been opened.
(continuation on Web Flow)But it is monolithic and will force us to rewrite the whole project. Yes, I know it supports JSF and I have tested and fumbled with it for a little while to see whether it fits the bill or not. It doesn't because of its security. Unfortunately we don't have time nor resources to build a new project from scratch.
We have almost run out of solutions. JSF is a great framework, has been tested extensively and used in many projects. But the developers refuse to include CDI in it.
Can anyone recommend any solution to edit-view-save problem with a single bean? Any architectural advice will be of great help. Thank you so much in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先：这与其说是一个问题，不如说是一次讨论，所以永远不会有明确的“是”或“否”...除了客观论证之外，总是有优点和缺点（开发人员不喜欢它) ;-)
无论如何，让我首先确定您的情况对于所有类型的 Web 应用程序来说都很常见，并且您所描述的问题对于每个从架构角度思考 Web 应用程序开发的人来说更为常见看法。
一年前面临着几乎相同的场景，这是我们的架构：
Java EE 6 与 JSF 2.0、CDI（+ EJB 3 和 JPA，但这超出了本答案的范围）。
所有这些都像一个魅力，之间几乎没有粘合代码各层。
我绝对支持你。这就是我们使用对话的原因。
凭借 3 年 Seam 2 / 3 的生产经验，我向您保证这绝对是可以管理的。对话就像手套一样适合某个用例，一段时间后您就不想再使用其他任何东西了。当然不是会议;-)
如果您想使用 CODI，则不需要 Weld，两者都是 JSR 299 实现。在撰写本文时，Weld 的文档更加完善，使用也更加频繁。我什至不知道CODI是否是最终的？
Seam / Weld / CODI 也解决了多选项卡问题。就这样九十了...
JSF 的问题在于您的项目不是全新项目。您需要连接到后端，而使用纯JSF范围和技术将会遇到问题。
我只能告诉你：我也必须说服我的同事使用 CDI。我用所描述的布局中的工作原型完成了它，现在，一年后，团队中的每个人都对我们的技术堆栈非常满意...:-)
总结这个相当冗长的答案：
Java EE 6 是伟大的技术堆栈这类应用程序，您应该尝试一下。您所描述的问题不仅可以通过 Java EE 6解决，而且是规范团队在设计 API 时考虑的问题。
如果您愿意，请随时发布更多问题/疑虑。
First of all: this is rather a discussion than a question, so there will never be a clear 'yes' or 'no'... There are always pros and cons beyond objective arguments (the developers dont like it) ;-)
Anyhow, let me start with the ascertainment that your situation is very common for all kind of web applications, and the problems you are describing are even more common for everyone who thinks about web application development from a architectural point of view.
Being confronted with an almost identical scenario over a year ago, here is our architecture:
Java EE 6 with JSF 2.0, CDI ( + EJB 3 & JPA, but this is beyond the scope of this answer).
All this works like a charm, with almost no glue code between the layers.
I'm absolutely with you. That's why we use conversations.
With 3 years experience of Seam 2 / 3 in production, I assure you that this is absolutely manageable. A conversation fits a usecase like a glove, and after a while you don't want to use anything else again. And certainly not the session ;-)
If you want to use CODI you dont need Weld, both are JSR 299 implementations. At the time of writing, Weld is far better documented and used more often. I don't even know if CODI is final?
The multitab problem is solved by Seam / Weld / CODI as well. That's so ninetieths...
The problem with JSF is that your projects are not greenfield. You need to connect to a backend, and you will have problems doing this with pure JSF-scopes and technologies.
All I can tell you: I too had to convince my co-workers to use CDI. I did it with a working prototype in the described layout, and now, a year later everyone in the team is quite happy with our technology stack... :-)
To summarize this rather lengthy answer:
Java EE 6 is great technology stack for that kind of applications, and you should give it a try. The problems you are describing are not only solvable with Java EE 6, instead they were rather the problems the spec team had in mind when they designed the APIs.
Feel free to post further questions / doubts, if you like.
一般说明：
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
Just a general note:
OpenWebBeans, Weld and CanDI are JSR-299 implementations, thus the real containers providing the functionality of managing contextual instances, contexts, events, etc.
CODI is a portable JSR-299 Extension (like Seam3 is) which will run on any CDI container. You can use CODI on all the CDI-containers mentioned above.
CODI basically provides a few different things:
1.) a core module which contains useful stuff like @ProjectStageActivated (enabling/disabling beans based on the JSF ProjectStage), injectable Messages,
2.) JSF support modules with lots of additional scopes like @ViewAccessScoped, @WindowScoped (bean per window), @ConversationGroup, type safe @View navigation, CDI @PhaseListener, etc
3.) JPA @Transactional support. This will give you easy persistence without the need of using EJBs