我正在使用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是有意义的？
京公网安备 11010802040832号 | 京ICP备19059560号-6 