我正在使用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是有意义的？
答案 0 :(得分：1)
我在使用JPA，EJB3和Wicket构建webapp时遇到了困难。由于使用重复查询来查找数据库比在内存中保存大量实体更具可扩展性，因此我决定只传递它们的ID而不是实体本身。
Wicket及其模型概念与此决定有很大关系。他们的loadableDetachableModel在不使用时清理实体，同时仍然保持id。实现了一个load（）方法，它知道如何在需要时再次获取实体，在我的例子中，通过调用无状态会话bean;并且persist（）方法调用无状态bean来持久化更改。这个模型类是我实际传递的。 Wicket只处理与显示和输入验证有关的逻辑，我只需要将ejb注入模型类。也许你可以在你的应用程序中创建类似的东西（我不知道电梯提供什么......）。
对我来说这很好用，但我没有特别复杂的业务逻辑，可以隔离任何需要持久保存到小单位逻辑和单页的更改。
答案 1 :(得分：0)
每当您需要许多“系统”服务（注入等）时，请使用无状态bean。 否则 - POJO。 POJO更灵活。
然而，简单的（访问者？）方法（例如在webservices和bean中）可以做一些简单的工作并返回结果。