一个用于实用程序功能的无状态会话 EJB？答案

【问题标题】：One Stateless Session EJB for Utility functions?一个用于实用程序功能的无状态会话 EJB？
【发布时间】：2016-01-15 13:57:39
【问题描述】：

我有一些可以从多个无状态会话 EJB 调用的实用程序函数。这些实用功能需要在新事务中 (RequiresNew)。

为所有这些功能创建一个无状态会话 EJB 是否有意义，可以称之为Utility？

或者我应该尝试让它们按功能组织，在这种情况下我会得到多个无状态会话 EJB？如果我有很多这样的无状态会话 EJB，对系统性能会有什么影响？

效用函数的一些例子：

我有一个表，用于存储带有 ID 的消息。创建一个实用函数来检索特定 ID 的消息。创建一个实用函数来更新特定 ID 的消息。
我有一张表格，用于跟踪某些进程的状态。创建一个实用函数来给出特定进程的状态。创建一个实用函数来更新特定进程的状态。

等等。

【问题讨论】：

你能给我们举几个函数的例子吗？
如果他们需要一个新的交易（和状态），他们绝对不是“实用功能”。
根据您的编辑：这些只是 MessageService 和 ProcessService EJB？或者您不知道您可以在一个 EJB 中安全地注入另一个 EJB？实用函数是类中的静态方法，没有任何实例变量。
@BalusC 这些函数需要新事务，因为它们可能是从另一个事务中调用的，并且无论调用事务的提交或回滚如何都希望这些函数提交
这完全可行，但绝对不是“实用功能”。

标签： java jakarta-ee transactions ejb utility-method

【解决方案1】：

从性能的角度来看，对于每个无状态 EJB，容器必须实例化和管理一个包含该 bean 实例的 bean 池。（这通常不大，因为无状态 bean 可以互换使用。我相信 JBoss AS 中的默认值是 20 instances/pool）如果将它们组合到一个 bean 中，则只需要一个池，但它可能需要更多实例，因为它们必须服务于所有类型的调用。所以性能不会受到明显影响。

更大的问题是封装 - 拥有一个“实用程序”会话 bean 将完全违反关注点分离，它会让您拥有一个具有许多不同目的和依赖关系的类。它有成为Ball of Mud 的风险，会混合所有方法的依赖关系，并且会使您的代码更难维护，因为更难找出这些函数的位置。

我强烈建议您多考虑是否有有意义的功能单元可以将这些方法分开，即使它们都很小。正如其他评论者所建议的那样，您的两个示例听起来很适合 ProcessService 和 MessageService。您可能会发现，当您查看要添加的功能集时，它们并不是划分事物的最佳方式，但这可能是一个很好的起点。如果您现在就努力确定系统中不同的逻辑服务是什么，您将在以后获得可扩展性和可维护性方面的回报。

【讨论】：