我目前正在开发一个基于 JavaEE 的大型软件。我们遵循 JavaEE 的一般准则，即每组相关的操作都应该进入它们自己的 EJB。我们目前有超过 275 个不同的 EJB 类（无状态会话 bean）。这个数字很可能会增长到至少两倍。
我想知道 EJB 容器是否设计为容纳这么多不同类型的 EJB。我很想知道我们是否会因为拥有太多这样的类而导致一些糟糕的性能损失，以及一些应用程序服务器级别的调整是否可以帮助缓解这些假设性问题。
我们在 sun 的 Java 6 上使用带有 JavaEE 5 的 Glassfish v2，因此非常感谢有关此特定平台的建议。
EJB 应该是细粒度的，因此如果您在设计中保持一致，那么您所做的事情就没有问题。
EJB 只是类，所以除了一般负载之外没有什么可担心的，这与您部署的 EJB 的数量正交。
如果您担心性能，请输入一些监控或其他性能指标，并在添加新功能时查看情况如何。
归根结底，你宁愿维护更少的类和很多方法，还是维护很多类和更少的方法？我知道我会选哪一个。
（有没有办法我可以说“任何”而不会被否决？）
严肃地说，尽可能多地使用。我的经验法则是（对于一般的 EJB 和类），如果你不能用大约三个词的类名来完全描述事物的作用，那么你就做得太多了。
就性能而言，我怀疑如果系统开始遭受“太多 EJB”的困扰，那么您在某个地方就会遇到更大的问题。
EJB 是组件而不是类，您应该在这个术语中考虑它们并适当地表达您的系统设计。
组件的粒度显然取决于域。
假设您正在使用 EJB 对（相当老式的）计算机进行建模。电阻器、晶体管、线圈等：这些都是 pojos。芯片和电路板是组件。组件是 EAR。
接口粒度应反映组件功能。
EJB 不仅仅是普通的类实例。它需要在容器、实例池等方面进行额外维护。许多 EJB 需要服务器中的大量资源。
我不认为一个系统确实需要数百个 EJB。虽然我还参与了一个包含 90 个 EJB 的应用程序，但这是一场噩梦：< 没有可测试性，部署也是一项艰巨的任务。