您是否认为将所有广泛使用的实用程序方法放在应用程序范围的bean中是个好主意?
在我正在处理的应用程序的当前实现中,所有实用程序方法(使用字符串操作,cookie,检查URL,检查用户所在的当前页面等)都放在一个大的请求范围内的bean中从每个xhtml页面引用。
如果将实用程序方法放在应用程序作用域中的方法是一个好的或坏的选择,我找不到有关stackoverflow的任何信息。
为什么我遇到这个想法是需要在范围更广的bean中重用那些方法,然后是请求范围的bean(如视图或会话范围的bean)。如果我错了,请纠正我但你应该总是注入相同或更宽的范围bean,即你不应该在视图范围内注入请求范围的bean。
我认为使用应用程序作用域bean中的实用程序方法应该是有益的(不会有任何新的对象创建,将在所有应用程序中创建和重用一个对象),但我仍然希望得到确认或某人告诉我这是不是错误的做法,为什么是错的。
答案 0 :(得分:11)
对于bean范围,如果bean没有任何状态(即该类没有任何可变的实例变量),那么它可以安全地应用于作用域。另请参阅How to choose the right bean scope?这一切都与bean的目的无关(实用程序与否)。鉴于实用程序函数是按定义无状态的,那么您肯定应该使用应用程序作用域bean。它节省了在每个请求上实例化的成本。
至于在托管bean中使用实用程序方法,从面向对象的角度来看,这是一种不好的做法,因为为了从EL访问它们,这些方法不应该是static
。您不能将它们用作其他普通Java类中的实用方法。像Sonar这样的静态代码分析器会用大红旗标记它们。因此,这是一种反模式。正确的方法是继续使用真实用工具类(public final class
与private Constructor()
仅使用static
方法)并将所有static
方法注册为{{1中的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
文件。它会自动将给定类型的所有your.taglib.xml
方法导出到EL函数范围。
public static
如果您不使用OmniFaces,并且这一切都是供内部使用,那么我可以想象重做所有<o:importFunctions type="com.example.Utils" var="u" />
...
<x:foo attr="#{u:foo(bean.property)}" />
注册样板的每个微型实用功能突然弹出都变得很烦人。我可以合理化和原谅滥用应用程序范围的bean用于这种“仅限内部使用”的情况。只有当你开始外化/模块化/公开它时,你才应该将它们注册为EL功能,而不是将不良做法公开。