使用不可序列化的 EntityManager 进行有状态会话 bean 钝化？
我刚刚读过 Adam 的为什么有状态和本地反立面是 KISS Bien 建议使用带有 EntityManager 的 SFSB 来在整个客户端交互期间保持实体的附加状态。
这是否不会在评论中提到的集群环境中失败，而且每当 SFSB 应由容器钝化时也会失败？
如果我是对的，您会建议什么样的解决方案？我认为，为了最大限度地减少应用程序中的层数，将 SFSB 绑定到对话范围然后直接在我的 JSF 视图中引用它们会很有用。
I have just read Why stateful and local anti-facades are KISS by Adam Bien where he suggests using a SFSB with an EntityManager to keep entities attached during the whole client interaction.
Does't this fail not in a clustered environment as mentioned in a comment but also whenever the SFSB should be passivated by the container?
If I'm right what kind of solution would you suggest? I thought to minimize the number of layers in the application it would be useful to bind the SFSBs to conversation scope and then reference them directly in my JSF views.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，拥有基于状态的架构是可逆扩展的。
我在多个项目中使用 EJB 3 SLSB 已经超过 5 年了，在合并实体方面从未遇到过真正的问题。
如果您愿意，可以通过添加 DTO 层将客户端层与持久层分离。通过这种方式，您可以根据最适合业务/持久层的方式设计实体模型，并根据客户想要呈现数据的方式设计 DTO。
如果您想使用相同的对象，您仍然可以这样做，您应该只注意哪些对象在“会话中”以及哪些对象已分离，并且不会遇到任何合并问题。
In general, having a stateful based architecture is counter scalable.
I have been working with EJB 3 SLSBs for over 5 years now in multiple projects and never had a real issue with merging entities.
If you want to you can decouple your client layer from your persistence layer by adding a layer of DTOs. This way you can design your entity model according to what's best for the business/persistence layer and your DTOs according to the way your client wants to present the data.
If you want to use the same objects you can still do that, you should only pay attention to which objects are "in the session" and which are detached, and you won't have any merge issues.