Почему SpringCon ApplicationContext.getBean считается плохим?

Question

Я задал общий вопрос Spring: Auto-cast Spring Beans , и несколько человек ответили, что вызова Spring'а ApplicationContext.getBean() следует избегать, насколько это возможно. Это почему?

Как еще мне получить доступ к bean-компонентам, которые я настроил для создания Spring?

Я использую Spring в не-веб-приложении и планировал доступ к общему ApplicationContext объекту , как описано LiorH .

Поправка

Я принимаю ответ ниже, но вот альтернативный вариант Мартина Фаулера, который обсуждает преимущества внедрения зависимостей по сравнению с использованием локатора служб (что по сути то же самое, что вызов свернутого ApplicationContext.getBean()) .

В частности, Фаулер заявляет: « С помощью локатора службы класс приложения запрашивает его [службу] явным образом посредством сообщения локатору. При внедрении явный запрос отсутствует, служба появляется в классе приложения - отсюда и инверсия контроля. Инверсия контроля - это общая черта фреймворков, но это то, что имеет свою цену. Как правило, это трудно понять и приводит к проблемам при попытке отладки. В общем, я предпочитаю избегать этого [инверсии контроля], если мне это не нужно. Это не значит, что это плохо, просто я думаю, что нужно оправдать себя более простой альтернативой."

Answer 1

Есть другое время, когда использование getBean имеет смысл. Если вы реконфигурируете систему, которая уже существует, где зависимости явно не вызываются в весенних контекстных файлах. Вы можете начать процесс, введя вызовы getBean, чтобы вам не приходилось подключать все сразу. Таким образом, вы можете постепенно наращивать конфигурацию пружины, со временем размещая каждый элемент на месте и правильно расставляя биты. Вызовы getBean в конечном итоге будут заменены, но, когда вы поймете структуру кода или его отсутствие, вы можете начать процесс подключения все большего числа компонентов и использовать все меньше и меньше вызовов getBean.

Answer 2

Я обнаружил только две ситуации, когда требуется getBean ():

Другие упоминали об использовании getBean () в main () для извлечения "основного" bean-компонента для отдельной программы.

Другое использование getBean (), которое я использовал, - это ситуации, когда интерактивная конфигурация пользователя определяет структуру bean-компонента для конкретной ситуации. Так, например, часть загрузочной системы проходит по таблице базы данных, используя getBean () с определением компонента scope = 'prototype', а затем устанавливает дополнительные свойства. Предположительно, существует пользовательский интерфейс, который настраивает таблицу базы данных, что было бы более удобным, чем попытка (пере) записи контекста приложения в XML.

Answer 3

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