为什么我不应该使用 JSF SessionScoped bean 来实现逻辑？
我正在使用 JSF 和购物车样式流程开发一个 java EE Web 应用程序，因此我想收集多个页面上的用户输入，然后用它做一些事情。
我正在考虑为此使用 EJB 3 有状态会话 bean，但我的研究使我相信 SFSB 并不与客户端的 http 会话绑定，因此我必须通过 httpSession 手动跟踪它，一些附带问题这里 。 。 。
1）为什么它被称为会话bean，据我所知它与会话无关，我可以通过在会话中存储pojo来实现相同的目的。
2）如果我要注入的只是这个 SFSB 的一个新实例，那么我还可以使用 pojo 吗？能够注入它有什么意义？
回到我看到的主要问题，JSF 是一种表示技术，因此它不应该用于逻辑，但它似乎是收集用户输入的完美选择。
我可以将 JSF 会话作用域 bean 设置为所有请求 bean 的托管属性，这意味着它会注入到它们中，但与 SFSB 不同，JSF 托管会话作用域 bean 与 http 会话绑定在一起，因此始终会注入相同的实例只要 http 会话尚未失效。
因此，我有多个层（
第一层）JSF 托管请求作用域 bean，用于处理表示，每页 1 个。
第二层）一个 JSF 管理的会话范围 bean，其值由请求 bean 设置。
第三层）无状态会话 EJB，对 JSF 会话作用域 bean 中的数据执行逻辑。
为什么情况这么糟糕？
另一种选择是使用 SFSB，但是我必须将它注入到我的初始请求 bean 中，然后将其存储在 http 会话中，并在每个后续请求 bean 中将其取回 - 看起来很混乱。
或者我可以将所有内容存储在会话中，但这并不理想，因为它涉及使用文字键和强制转换。等等..等等这很容易出错。 。 。又乱！
任何想法都值得赞赏，我觉得我是在对抗这项技术，而不是使用它。
谢谢
I'm developing a java EE web app using JSF with a shopping cart style process, so I want to collect user input over a number of pages and then do something with it.
I was thinking to use an EJB 3 stateful session bean for this, but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .
1) Why is it called a session bean, as far as I can see it has nothing to do with a session, I could achieve the same by storing a pojo in a session.
2) What's the point of being able to inject it, if all I'm gonna be injecting' is a new instance of this SFSB then I might as well use a pojo?
So back to the main issue I see written all over that JSF is a presentation technology, so it should not be used for logic, but it seems the perfect option for collecting user input.
I can set a JSF session scoped bean as a managed property of all of my request beans which means it's injected into them, but unlike a SFSB the JSF managed session scoped bean is tied to the http session and so the same instance is always injected as long as the http session hasn't been invalidated.
So I have multiple tiers
1st tier) JSF managed request scoped beans that deal with presentation, 1 per page.
2nd tier) A JSF managed session scoped bean that has values set in it by the request beans.
3rd tier) A stateless session EJB who executes logic on the data in the JSF session scoped bean.
Why is this so bad?
Alternative option is to use a SFSB but then I have to inject it in my initial request bean and then store it in the http session and grab it back in each subsequent request bean - just seems messy.
Or I could just store everything in the session but this isn't ideal since it involves the use of literal keys and casting . etc .. etc which is error prone. . . and messy!
Any thoughts appreciated I feel like I'm fighting this technology rather than working with it.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更正：EJB 会话与 HTTP 会话无关。在 EJB 中，粗略地说，客户端是 servlet 容器，服务器是 EJB 容器（两者都运行在 Web/应用程序服务器中）。在 HTTP 中，客户端是 Web 浏览器，服务器是 Web/应用程序服务器。
现在更有意义了吗？
使用 EJB 执行事务性业务任务。使用会话范围的托管 bean 来存储 HTTP 会话特定数据。顺便说一句，两者都不是 POJO。只是爪哇豆。
如果您没有利用事务性业务任务以及 EJB 围绕它提供的抽象，那么只需在简单的 JSF 托管 bean 中执行即可确实是一个不错的选择。这也是基本 JSF 应用程序中的常规方法。然而，这些操作通常在请求范围的托管 bean 中进行，其中会话范围的托管 bean 作为 @ManagedProperty 注入。
但既然您已经在使用 EJB，我会怀疑是否没有使用 EJB 的具体原因。如果这是上级的业务要求，那么我就会坚持下去。至少，您的会话混乱现在应该被清除了。
Correction: an EJB session has nothing to do with a HTTP session. In EJB, roughly said, the client is the servlet container and the server is the EJB container (both running in a web/application server). In HTTP, the client is the webbrowser and the server is the web/application server.
Does it make more sense now?
Use EJB for transactional business tasks. Use a session scoped managed bean to store HTTP session specific data. Neither of both are POJO's by the way. Just Javabeans.
If you aren't taking benefit of transactional business tasks and the abstraction EJB provides around it, then just doing it in a simple JSF managed bean is indeed not a bad alternative. That's also the normal approach in basic JSF applications. The actions are however usually to be taken place in a request scoped managed bean wherein the session scoped one is been injected as a
@ManagedProperty.But since you're already using EJB, I'd question if there wasn't a specific reason for using EJB. If that's the business requirement from upper hand, then I'd just stick to it. At least, your session-confusion should now be cleared up.
以防万一您没有意识到这一点，并且作为对您所拥有的答案的一个小贡献，您确实可以使用 @SessionScoped 注释 SFSB，并且 CDI 将处理 EJB 的生命周期...这将绑定 EJB到 CDI 管理的 Http 会话。只是让您知道，因为在您的问题中您说：
另外，您可以按照您的建议进行操作，但这取决于您的要求，直到 CDI bean 获得声明性事务支持或扩展持久性上下文等，您会发现自己编写了很多样板代码会使你的 bean 不太干净。当然，您也可以使用像 Seam 这样的框架（现在转向 DeltaSpike）来增强 Bean 的某些功能通过他们的扩展。
所以我想说是的，乍一看您可能会觉得没有必要使用有状态 EJB，但某些用例可能通过它们可以更好地解决。如果一个用户将一种产品添加到他的购物车，而另一个用户稍后添加了相同的产品，但库存只有一个单位，那么谁会得到它？结账速度更快的人？或者是第一个添加它的人？如果您想访问实体管理器来持久保存卡丁车，以防用户决定随机关闭浏览器，或者如果您有生成多个页面的事务并且您希望每个步骤都同步到数据库，该怎么办？ （不建议长时间保持事务打开，但也许可能存在需要这样做的情况？）您可以使用 SLSB，但有时使用 SFSB 更好、更干净。
Just in case you're not aware of this, and as a small contribution to the answers you have, you could indeed anotate a SFSB with @SessionScoped, and CDI will handle the life cycle of the EJB... This would tie an EJB to the Http Session that CDI manages. Just letting you know, because in your question you say:
Also, you could do what you suggest, but it depends on your requirements, until CDI beans get declarative transaction support or extended persistence contexts etc, you'll find yourself writing a lot of boilerplate code that would make your bean less clean. Of course you can also use frameworks like Seam (now moving to DeltaSpike) to enhance certain capabilities of your beans through their extensions.
So I'd say yes, at first glance you may feel it's not necessary to use a stateful EJB, but certain use cases may be better solve through them. If a user adds a product to his cart, and another user adds this same product later, but there is only one unit in stock, who gets it? the one who does the checkout faster? or the one who added it first? What if you want to access your entity manager to persist a kart in case the user decides to randomly close his browser or what if you have transactions that spawn multiple pages and you want every step to be synchronized to the db? (To keep a transaction open for so long is not advisable but maybe there could be a scenario where this is needed?) You could use SLSB but sometimes it's better and cleaner to use a SFSB..
来自旧的 J2EE 1.3 教程：
所以它与“会话”有关。但session并不一定意味着“HTTP会话”
好吧，首先，你不要在无状态组件中注入 SFSB（注入另一个 SFSB 就可以了），你必须进行查找。其次，在 HTTP 会话和 SFSB 之间进行选择实际上取决于您的应用程序和需求。从纯粹的理论角度来看，HTTP 会话应该用于表示逻辑状态（例如，您处于多页面表单中的位置），而 SFSB 应该用于业务逻辑状态。这在“旧” HttpSession 与 Stateful session beans 中得到了很好的解释TSS 上的线程也有一个很好的例子，其中 SFSB 有意义：
但 SFSB 并不简单，如果您不需要证明其使用的合理性，我的实用建议是坚持使用 HTTP 会话（特别是如果这一切对您来说都是新的）。以防万一，请参阅：
这不是业务逻辑，而是表示逻辑。
不。您可能有一个客户端层、一个表示层、一个业务层、一个数据层。你所描述的看起来更像是图层（甚至不确定）。请参阅：
我不知道，我不知道你在说什么:)但是你可能应该将多页表单信息收集到 SessionScoped bean 中并调用无状态会话 Bean (SLSB)在该过程结束时。
From the old J2EE 1.3 tutorial:
So it has to do with a "session". But session not necessarily means "HTTP session"
Well, first of all, you don't inject a SFSB in stateless component (injection in another SFSB would be ok), you have to do a lookup. Secondly, choosing between HTTP session and SFSB really depends on your application and your needs. From a pure theoretical point of view, the HTTP session should be used for presentation logic state (e.g. where you are in your multi page form) while the SFSB should be used for business logic state. This is nicely explained in the "old" HttpSession v.s. Stateful session beans thread on TSS which also has a nice example where SFSB would make sense:
But SFSB are not simple and if you don't have needs justifying their use, my practical advice would be to stick with the HTTP session (especially if all this is new to you). Just in case, see:
That's not business logic, that's presentation logic.
No. You have probably a client tier, a presentation tier, a business tier, a data tier. What you're describing looks more like layers (not even sure). See:
I don't know, I don't know what you're talking about :) But you should probably just gather the multi page form information into a SessionScoped bean and call a Stateless Session Bean (SLSB) at the end of the process.