Последствия неправильной инициализации пружины

Question

Я работаю с неправильно скомпонованным приложением пружины. Вместо использования IOC объекты, для которых требуются ссылки, извлекают свои ссылки из контекста:

    BeanFactory b = SingletonBeanFactoryLocator.getInstance().
               useBeanFactory("factory").getFactory();
    Bean foo = (FOO)beanFactory.getBean("foo");

Если оставить в стороне конструкцию, не относящуюся к МОК, каковы другие отрицательные последствия этого? Например, имеет ли это какое-то конкретное влияние на производительность? Есть ли способ, которым это может привести к созданию дополнительных контекстов или ссылок на объекты? Что-нибудь еще действительно неприятное, что это может вызвать?

Answer 1

Я считаю, что единственная реальная «проблема производительности» - это дополнительные вызовы getBean (); если это вызывать очень много раз, это может оказать влияние. Также важно учитывать, насколько дорогими являются другие операции в этом контексте: если вы делаете что-то вроде запроса к базе данных или подключения с большой задержкой к другой сети, это, вероятно, не будет значительным. Но если это происходит в контексте обновления экрана при программировании GUI, то это может быть очень дорого.

Любые другие функции, предоставляемые Spring (AOP, bean-объекты и т. Д.), Будут работать одинаково, независимо от того, вводится объект или извлекается из контейнера.

Answer 2

На ум приходит старая фраза «вы можете программировать на любом языке». Использование весны в качестве сервисного локатора звучит так, как будто вы упускаете большинство вещей, которые делают весну приятной. Spring тоже не очень хороший сервисный локатор. Это также затрудняет выполнение модульных тестов, поскольку вы теряете некоторые действительно хорошие слабые связи. (Вы затягиваете муфту таким образом)

ИМО, достаточно, чтобы эти аргументы были причиной конверсии Я бы даже не стал говорить о производительности, на что другие указали, что маловероятно, если вы не зациклены.

С другой стороны, вы, вероятно, действительно легко можете конвертировать в аннотации пружин, что, вероятно, является причиной, по которой первоначальный автор вашего кода не сделал "правильную" пружину; ему не нравились все xml. С аннотациями вам не нужен весь этот xml.

Answer 3

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

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