Полезные методы в области применения бобов

Question

Считаете ли вы хорошей идеей помещать все широко используемые служебные методы в компонент приложения?

В текущей реализации приложения, над которым я работаю, все служебные методы (манипуляции со строками, куки-файлы, проверка URL, проверка текущей страницы, где находится пользователь и т. Д.) Все помещаются в один большой объектный боб, и на них ссылаются из каждая страница HTML.

Я не смог найти никакой информации о стековом потоке, если подход использования служебных методов в компоненте, определяемом приложением, был бы хорошим или плохим выбором.

Почему я натолкнулся на эту идею, так это необходимость повторного использования этих методов в bean-компоненте более широкой области действия, чем bean-объект с областью запроса (например, bean-объект вида или сессия). Поправьте меня, если я ошибаюсь, но вы всегда должны внедрять бины одинаковой или более широкой области, то есть вы не должны внедрять бин с областью запроса в область видимости.

Я думаю, что использование утилитарных методов из bean-объекта scoped должно быть полезным (не будет никаких новых созданий объектов, один объект будет создан и повторно использован во всем приложении), но все же я хотел бы получить подтверждение или кто-то, чтобы сказать мне, если Это неправильный подход и почему это неправильно.

Answer 1

Что касается области действия bean-компонента, то, если bean-компонент не имеет никакого состояния (т. Е. У класса нет изменяемых переменных экземпляра), он может быть безопасно ограничен областью применения. Смотрите также Как правильно выбрать сферу применения бобов? Это все независимо от назначения бина (полезность или нет). Учитывая, что служебные функции по определению не имеют состояния, то вам определенно следует использовать компонент приложения. Это экономит затраты на создание экземпляров для каждого отдельного запроса.

Что касается использования служебных методов в управляемом компоненте, то в объектно-ориентированной перспективе это плохая практика, потому что для доступа к ним из EL эти методы не могут быть static пока они должны быть. Вы не можете использовать их в качестве реальных служебных методов в других обычных классах Java. Статические анализаторы кода, такие как Sonar, будут отмечать их большим красным флажком. Таким образом, это анти-паттерн. Правильный подход заключается в том, чтобы продолжать использовать настоящий служебный класс (public final class с private Constructor() исключительно static методы) и зарегистрировать все эти static методы как EL функции в your.taglib.xml как описано в разделе Как создать пользовательскую функцию EL для вызова статического метода?

По крайней мере, это то, что вам следует делать, когда вы собираетесь использовать общедоступную библиотеку, такую ​​как JSTL. fn:xxx(), PrimeFaces p:xxx() или OmniFaces of: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 и не раскрывать плохие методы для общественности.