6

我正在使用 EJB3（Hibernate + Glassfish 用于应用程序和 Web 服务层，Lift on Glassfish 用于 Web UI）在 Java 中开发多层金融处理应用程序，我正在努力解决在哪里的问题把我的业务逻辑。

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

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

我的基本问题是：您可以建议哪些原则和指导方针来决定业务逻辑应该放在会话 bean 中还是 POJO 中？给定一个复杂的对象图，什么时候传递实体 bean 才有意义？

4

2 回答 2

1

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

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

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

于 2008-11-07T23:22:41.750 回答
0

每当您需要许多“系统”服务（注入等）时，请使用无状态 bean。否则 - POJO。POJO 更加灵活。

然而，简单的（访问器？）方法（例如在 web 服务和 bean 中）只能做一些简单的工作并返回结果。

于 2008-10-30T20:01:05.563 回答