应用程序范围的Bean中的实用程序方法 [英] Utility methods in application scoped bean

问题描述

您认为将所有广泛使用的实用程序方法放入应用程序范围的Bean中是一个好主意吗?

Do you think it is a good idea to put all widely used utility methods in an application scoped bean?

在我正在处理的应用程序的当前实现中，所有实用程序方法(使用字符串，cookie，检查url，检查用户所在的当前页面等)都放在一个大请求范围内的bean中，并且它们是每个xhtml页面都引用的.

In the current implementation of the application I'm working on, all utility methods (manipulating with Strings, cookies, checking url, checking current page where the user is etc.) are all put in one big request scoped bean and they are referenced from every xhtml page.

如果将实用程序方法放入应用程序范围的Bean中的方法是好是坏，我找不到关于stackoverflow的任何信息.

I couldn't find any information on stackoverflow if the approach of putting utility methods in an application scoped bean would be a good or a bad choice.

为什么我遇到这个想法，是需要在范围比请求范围的bean(例如，视图或会话范围的bean)更宽的bean中重用这些方法.如果我错了，请纠正我，但您应该始终注入相同或更大范围的Bean，即，不应在请求范围的视图内注入请求范围的Bean.

Why I came across this idea is the need of reusing those methods in a bean of a wider scope then a request scoped bean (like view or session scoped bean). Correct me if I'm wrong but you should always inject same or wider scoped beans i.e. you shouldn't inject request scoped bean inside a view scoped one.

我认为使用应用程序范围的Bean的实用程序方法应该是有益的(不会创建任何新的对象，将在所有应用程序中创建并重新使用一个对象)，但是我还是希望得到确认或有人告诉我这是否是错误的方法，为什么会错误.

I think using utility methods from application scoped bean should be beneficial (there won't be any new object creations, one object will be created and re-used across all application), but still I would like a confirmation or someone to tell me if that is a wrong approach and why is it wrong.

推荐答案

对于bean范围，如果bean没有任何状态(即，该类没有任何可变的实例变量)，那么它可以安全地运行在应用程序范围内.另请参见如何选择正确的bean作用域?不管bean的用途是什么(实用程序与否).鉴于实用程序函数按定义是无状态的，那么您绝对应该使用应用程序范围的Bean.这样可以节省在每个请求上实例化的成本.

As to the bean scope, if the bean doesn't have any state (i.e. the class doesn't have any mutable instance variables), then it can safely be application scoped. See also How to choose the right bean scope? This all is regardless of the purpose of the bean (utility or not). Given that utility functions are per definition stateless, then you should definitely be using an application scoped bean. It saves the cost of instantiating on every single request.

对于在托管bean中使用实用程序的方法，从面向对象的角度来看，这是一种较差的做法，因为为了从EL中访问它们，这些方法不能在应有的情况下成为static.您不能在其他普通Java类中将它们用作实际的实用程序方法.诸如Sonar之类的静态代码分析器会将它们全部标记为红色大标志.因此，这是一种反模式.正确的方法是继续使用真正的实用程序类(public final class和private Constructor()一起使用static方法)，并将所有这些static方法注册为your.taglib.xml中的EL函数，如

As to having utility methods in a managed bean, in object oriented perspective this is a poor practice, because in order to access them from EL those methods cannot be static while they should be. You can't use them as real utility methods in other normal Java classes. Static code analyzers like Sonar will mark them all with a big red flag. This is thus an anti-pattern. The correct approach would be to keep using a true utility class (public final class with private Constructor() with solely static methods) and register all those static methods as EL functions in your.taglib.xml as described in How to create a custom EL function to invoke a static method?

至少，当您打算拥有一个公共可重用的库(例如 <o:importFunctions> .它将自动将给定类型的所有public static方法导出到EL函数范围中.

At least, this is what you should be doing when you intend to have a publicly reusable library such as JSTL fn:xxx(), PrimeFaces p:xxx() or OmniFaces of:xxx(). If you happen to use OmniFaces, then you could, instead of creating a your.taglib.xml file, reference the class in <o:importFunctions>. It will automatically export all public static methods of the given type into EL function scope.

<o:importFunctions type="com.example.Utils" var="u" />
...
<x:foo attr="#{u:foo(bean.property)}" />

如果您不使用OmniFaces，而所有这些都供内部使用，那么我可以想象，为每个突然弹出的小实用程序功能重做所有your.taglib.xml注册样板变得很烦人.对于这种仅供内部使用"的情况，我可以合理化和原谅滥用应用程序范围的Bean.仅当您开始对其进行外部化/模块化/公开时，才应将它们真正注册为EL函数，并且不要将不良做法暴露给公众.

If you don't use OmniFaces, and this all is for internal usage, then I can imagine that it becomes tiresome to redo all that your.taglib.xml registration boilerplate for every tiny utility function which suddenly pops up. I can rationalize and forgive abusing an application scoped bean for such "internal usage only" cases. Only when you start to externalize/modularize/publicize it, then you should really register them as EL functions and not expose poor practices into public.

这篇关于应用程序范围的Bean中的实用程序方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！