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