您认为将所有广泛使用的实用程序方法放在应用程序范围的 bean 中是个好主意吗？
在我正在处理的应用程序的当前实现中，所有实用程序方法（使用字符串、cookie、检查 url、检查用户所在的当前页面等）都放在一个大请求范围的 bean 中，它们从每个 xhtml 页面引用。
如果将实用程序方法放入应用程序范围的 bean 中是好还是坏的选择，我找不到有关 stackoverflow 的任何信息。
我遇到这个想法的原因是需要在一个范围更广的 bean 中重用这些方法，然后是请求范围的 bean（如视图或会话范围的 bean）。如果我错了，请纠正我，但您应该始终注入相同或更宽范围的 bean，即您不应该在视图范围内注入请求范围 bean。
我认为使用应用程序范围 bean 中的实用程序方法应该是有益的（不会创建任何新对象，将创建一个对象并在所有应用程序中重复使用），但我仍然希望得到确认或有人告诉我这是否是错误的方法以及为什么是错误的。
【问题讨论】：
标签： jsf jsf-2.2 application-scope
对于 bean 作用域，如果 bean 没有任何状态（即类没有任何可变实例变量），那么它可以安全地被应用程序作用域。另请参阅How to choose the right bean scope? 这一切都与 bean 的用途无关（实用程序与否）。鉴于实用程序函数根据定义是无状态的，那么您绝对应该使用应用程序范围的 bean。它节省了对每个请求进行实例化的成本。
关于在托管 bean 中拥有实用方法，从面向对象的角度来看，这是一种糟糕的做法，因为为了从 EL 访问它们，这些方法不能是 static，而它们应该是。您不能将它们用作其他普通 Java 类中的真正实用方法。像 Sonar 这样的静态代码分析器会用一个大红旗标记它们。因此，这是一种反模式。正确的方法是继续使用真正的实用程序类（public final class 和 private Constructor() 仅使用 static 方法）并将所有这些 static 方法注册为 your.taglib.xml 中的 EL 函数，如 How to create a custom EL function to invoke a static method? 中所述
至少，当您打算拥有一个可公开重用的库（例如 JSTL fn:xxx()、PrimeFaces p:xxx() 或 OmniFaces of:xxx()）时，您应该这样做。如果您碰巧使用 OmniFaces，那么您可以引用 <o:importFunctions> 中的类，而不是创建 your.taglib.xml 文件。它会自动将给定类型的所有public static 方法导出到EL 函数作用域中。
<o:importFunctions type="com.example.Utils" var="u" />
...
<x:foo attr="#{u:foo(bean.property)}" />
如果您不使用 OmniFaces，而这一切都是为了内部使用，那么我可以想象，为突然弹出的每个微小实用程序功能重做所有 your.taglib.xml 注册样板会变得很烦人。对于这种“仅限内部使用”的情况，我可以合理化并原谅滥用应用程序范围的 bean。只有当您开始将其外部化/模块化/公开时，您才应该真正将它们注册为 EL 函数，而不是将不良实践公开。
【讨论】：