多少个EJB才算太多？

Question

我目前正在开发一个基于JavaEE的大型软件。我们遵循了JavaEE的一般指导原则，即每个相关的操作集都应该进入它们自己的EJB中。我们目前有超过275个不同的EJB类(无状态会话bean)。这个数字很可能会增长到至少两倍。

我想知道EJB容器是否被设计为容纳那么多不同种类的EJB。我感兴趣的是，我们是否会因为拥有太多这样的类而得到一些糟糕的性能损失，以及一些应用服务器级别的调整是否可以帮助缓解这些假设问题。

我们正在sun的Java6上使用Glassfish v2和JavaEE 5，所以对这个特定平台的建议将不胜感激。

Answer 1

EJB应该是细粒度的，所以如果您的设计是一致的，那么您正在做的事情就不会有问题。

EJB只是类，所以除了一般的负载之外没有什么需要担心的，它与您部署的EJB的数量是正交的。

如果您担心性能，可以添加一些监控或其他性能指标，看看添加新功能时情况如何。

归根结底，您是更愿意维护更少的类和更多的方法，还是更愿意维护更多的类和更少的方法？我知道我会选哪一个。

Answer 2

(有没有一种方法，我可以说“任何”而不被投票否决？)

严肃地说，可以根据需要使用任意数量的代码。我的经验法则是(对于EJB和一般的类)，如果您不能在大约三个单词的类名中完整地描述事物的作用，那么您就让它做得太多了。

就性能而言，我怀疑如果系统开始受到“太多EJB”的影响，那么您在某个地方就会遇到更大的问题。

Answer 3

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

组件的粒度明显依赖于域。

假设您正在使用EJB为一台(相当老式的)计算机建模。电阻、晶体管、线圈等:这些都是pojos。芯片和电路板都是组件。集合就是耳朵。

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