有多少EJB太多了？

Question

我目前正在开发一个基于JavaEE的大型软件。我们遵循JavaEE的一般准则，即每个相关的操作集应该进入他们自己的EJB。我们目前有超过275种不同的EJB类（无状态会话bean）。这个数字最有可能增长到这个数字的两倍。

我想知道EJB容器是否设计用于容纳许多不同类型的EJB。我很想知道我们是否会因为有太多这样的类而导致性能损失，并且如果某些应用程序服务器级别的调整可以帮助减轻这些假设性问题。

我们在sun的Java 6上使用Glassfish v2和JavaEE 5，所以最喜欢这个特定平台的建议。

Answer 1

EJB应该是细粒度的，因此如果您的设计一致，那么您正在做的事情没有问题。

EJB只是类，因此除了一般加载之外没有什么可担心的，这与您已部署的EJB数量正交。

如果您担心性能问题，请提供一些监控或其他效果指标，并了解添加新功能后的情况。

在一天结束时，您宁愿使用多种方法维护较少的类，还是使用较少的方法维护许多类？我知道我选哪一个。

Answer 2

（有没有一种方式我可以说“任何”而不被投票？）

严肃地说，尽可能多地使用。我的经验法则是（对于EJB和类一般来说）如果你不能完全描述这个东西在大约三个单词的类名中的作用，你就会做得太多。

就性能而言，我怀疑如果系统开始遭受“太多EJB”的困扰，那么你在某处就会遇到更大的问题。

Answer 3

EJB是组件而不是类，您应该在该术语中考虑它们并适当地表达您的系统设计。

组件的粒度显然取决于域。

假设您正在使用EJB对（相当老式的）计算机进行建模。电阻器，晶体管，线圈等：这些都是pojos。芯片和电路板是组件。该装配是EAR。

接口粒度应反映组件功能。

Answer 4

EJB不仅仅是普通的类实例。它需要在容器，实例池等中进行额外的维护。很多EJB在服务器中需要很多资源。

我认为系统不需要数百个EJB。虽然我也参与了一个包含90个EJB的应用程序，但它却是噩梦：＆lt;没有可测试性，部署也是一项艰巨的任务。