EJB3业务逻辑模式和实践

Question

我正在使用EJB3(用于应用程序和Web服务层的Hibernate + Glassfish,用于Web UI的Glass on Glassfish)开发Java中的多层财务处理应用程序,我正在努力解决在何处使用把我的业务逻辑.

当这个项目开始时,我们的第一个想法是将大部分业务逻辑放入无状态会话bean中.但是,随着时间的推移,我们发现EJB框架提供的依赖注入过于局限,因此我们的许多业务逻辑最终都出现在由Guice在无状态会话bean的@PostConstruct方法中组装的POJO中. .这一进展导致我们的会话bean和POJO之间的业务逻辑分散,我正试图找出一种方法来纠正这个问题.

最初,我们尝试让我们的Web层使用会话bean的远程接口来执行一些可以从UI和Web服务层访问的功能,这些功能由@ WebService-annotated无状态会话bean提供.从持久性和性能的角度来看,这是一场噩梦,因为我们的实体图可能会变得非常大,并且将分离的实体图重新附加到持久化上下文,结果是非常容易出错,所以我们的解决方案是开始只是传递对象数据库周围的标识符,无论它们在何处需要,都可以从中查找实体.

我的基本问题是:您可以建议什么原则和指导方针来决定业务逻辑是应该进入会话bean还是POJO？在给定复杂的对象图的情况下,何时传递实体bean是有意义的？

Answer 1

我在使用 JPA、EJB3 和 Wicket 构建 Web 应用程序时遇到了这个问题。由于通过重复查询对数据库进行重击比在内存中保存大量大型实体更具可扩展性，因此我决定只传递它们的 id，而不传递实体本身。

Wicket 及其模型概念与这个决定有很大关系。他们的 loadableDetachableModel 会在实体不使用时清理它们，同时仍然保留 id。实现了一个 load() 方法，它知道如何在再次需要实体时获取该实体，在我的例子中是通过调用无状态会话 bean；persist() 方法调用无状态 bean 来保存更改。这个模型类是我实际传递的。Wicket 仅处理与显示和输入验证相关的逻辑，我只需将 ejb 注入到模型类中。也许您可以在您的应用程序中创建类似的东西（我不知道 lift 必须提供什么......）。

这对我来说效果很好，但我没有特别复杂的业务逻辑，并且可以将需要持久化为小逻辑单元和单页面的任何更改隔离开来。