EJB3 业务逻辑模式和 实践
我正在使用 EJB3（用于应用程序和 Web 服务层的 Hibernate + Glassfish，用于 Web UI 的 Glassfish 上的 Lift）开发一个多层财务处理应用程序，我正在努力解决在哪里开发的问题把我的业务逻辑。
当这个项目开始时，我们的第一个想法是将大部分业务逻辑放入无状态会话 bean 中。 然而，随着时间的推移，我们发现 EJB 框架提供的依赖注入过于有限，因此我们的许多业务逻辑最终都出现在由 Guice 在无状态会话 bean 的 @PostConstruct 方法中组装的 POJO 中。 这一进展导致会话 bean 和 POJO 之间的业务逻辑碎片化，我正在尝试找出纠正此问题的方法。
最初，我们尝试让 Web 层使用会话 Bean 的远程接口来执行一些可从 UI 和 Web 服务层访问的功能，这些功能由 @WebService 注释的无状态会话 Bean 提供。 从持久性和性能的角度来看，这被证明是一场噩梦，因为我们的实体图可能会变得非常大，并且将分离的实体图重新附加到持久性上下文非常容易出错，所以我们的解决方案是开始只传递对象周围的标识符并在需要的地方从数据库中查找实体。
我的基本问题是：您可以建议什么原则和准则来决定业务逻辑应该放在会话 bean 还是 POJO 中？ 给定一个复杂的对象图，什么时候传递实体 bean 才有意义？
I'm in the process of developing a multi-tiered financial processing application in Java using EJB3 (Hibernate + Glassfish for the app and web services layer, Lift on Glassfish for the web UI) and I'm struggling with the question of where to put my business logic.
When this project started, our first notion was to put the bulk of our business logic into the stateless session beans. As time has gone on, though, we've found the dependency injection provided by the EJB framework too limiting, so a lot of our business logic has ended up in POJOs that are assembled by Guice in the @PostConstruct method of the stateless session beans. This progress has led to fragmentation of our business logic between the session beans and the POJOs, and I'm trying to figure out an approach for correcting this.
Initially, we tried to have our web tier use the remote interfaces of the session beans to perform some functions that are accessible both from the UI and from the web service layer, which is provided by @WebService-annotated stateless session beans. This turned out to be a nightmare from a persistence and performance perspective, because our entity graph can grow quite large and reattaching the detached entity graph to the persistence context turned out to be highly error-prone, so our solution was to start just passing object identifiers around and looking up the entities from the database wherever they were needed.
My basic question is this: what principles and guidelines can you suggest for deciding whether business logic should go in a session bean or a POJO? When does it make sense to pass entity beans around, given a complex object graph?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在使用 JPA、EJB3 和 Wicket 构建 Web 应用程序时遇到了这个问题。 由于通过重复查询对数据库进行重击比在内存中保存大量大型实体更具可扩展性，因此我决定只传递它们的 id，而不传递实体本身。
Wicket 及其模型概念与这个决定有很大关系。 他们的 loadableDetachableModel 会在实体不使用时清理它们，同时仍然保留 id。 实现了一个 load() 方法，它知道如何在再次需要实体时获取该实体，在我的例子中是通过调用无状态会话 bean； persist() 方法调用无状态 bean 来保存更改。 这个模型类是我实际传递的。 Wicket 仅处理与显示和输入验证相关的逻辑，我只需将 ejb 注入到模型类中。 也许您可以在您的应用程序中创建类似的东西（我不知道电梯必须提供什么......）。
这对我来说效果很好，但我没有特别复杂的业务逻辑，并且可以将需要持久化为小逻辑单元和单页面的任何更改隔离开来。
I struggled with this while building a webapp using JPA, EJB3, and Wicket. Since hitting my database hard with repeated queries was more scalable than holding lots of large entities in memory, I decided to only pass around their ids and never the entity itself.
Wicket and its concept of models had a lot to do with this decision. Their loadableDetachableModel cleans up entities when they are not in use, while still holding on to the id. A load() method is implemented which knows how to get the entity when it is needed again, in my case by calling a stateless session bean; and a persist() method calls the stateless bean to persist changes. This model class is what I actually pass around. Wicket only handles logic pertaining to display and input validation, and I only need to inject the ejb into the model classes. Perhaps you could create something similar in your app (I've got no idea what lift has to offer...).
This has worked out nicely for me, but I don't have particularly complex business logic and can isolate any changes which need to be persisted into small units of logic and single pages.
每当您需要许多“系统”服务（注入等）时，请使用无状态 bean。
否则 - POJO。 POJO 更加灵活。
然而，简单的（访问器？）方法（例如在Web服务和bean中）只能做一些简单的工作并返回结果。
Whenever you need many "system" services (injections, etc) use stateless bean.
Otherwise - POJOs. POJOs are much more flexible.
However simple (accessor?) methods (e.g. in webservices and beans) can just do some simple work and return the results.