Warum wird ApplicationContext.getBean von Spring als schlecht angesehen?

Question

Ich habe eine allgemeine Frage zum Thema Frühling gestellt: Automatisch gegossene Frühlingsbohnen und mehrere Leute haben geantwortet, dass der Aufruf von Spring ApplicationContext.getBean() sollten so weit wie möglich vermieden werden. Warum ist das so?

Wie sollte ich sonst Zugriff auf die Beans erhalten, die ich mit Spring erstellt habe?

Ich verwende Spring in einer Nicht-Web-Anwendung und hatte geplant, den Zugriff auf eine freigegebene ApplicationContext Objekt wie von LiorH beschrieben .

Abänderung

Ich akzeptiere die unten stehende Antwort, aber hier ist eine andere Meinung von Martin Fowler, der erörtert die Vorzüge von Dependency Injection gegenüber der Verwendung eines Service Locators (was im Wesentlichen dasselbe ist wie der Aufruf einer umhüllten ApplicationContext.getBean() ).

Fowler erklärt unter anderem: " Beim Service Locator fordert die Anwendungsklasse den Dienst explizit durch eine Nachricht an den Locator an. Bei der Injektion gibt es keine explizite Anfrage, der Dienst erscheint in der Anwendungsklasse - daher die Umkehrung der Kontrolle. Die Umkehrung der Kontrolle ist ein gängiges Merkmal von Frameworks, aber sie hat ihren Preis. Sie ist in der Regel schwer zu verstehen und führt zu Problemen bei der Fehlersuche. Im Großen und Ganzen ziehe ich es also vor, sie [die Umkehrung der Kontrolle] zu vermeiden, wenn ich sie nicht brauche. Das soll nicht heißen, dass es etwas Schlechtes ist, ich denke nur, dass es sich gegenüber der einfacheren Alternative rechtfertigen muss. "

Answer 1

Es gibt noch einen weiteren Fall, in dem die Verwendung von getBean sinnvoll ist. Wenn Sie ein bereits bestehendes System rekonfigurieren, bei dem die Abhängigkeiten nicht explizit in den Spring-Kontextdateien aufgeführt sind. Sie können den Prozess beginnen, indem Sie Aufrufe an getBean einfügen, damit Sie nicht alles auf einmal verkabeln müssen. Auf diese Weise können Sie Ihre Spring-Konfiguration langsam aufbauen, indem Sie nach und nach alle Teile an ihren Platz setzen und die Teile richtig aneinanderreihen. Die Aufrufe von getBean werden schließlich ersetzt werden, aber wenn Sie die Struktur des Codes verstehen, können Sie damit beginnen, mehr und mehr Beans zu verdrahten und immer weniger Aufrufe von getBean zu verwenden.

Answer 2

Ich habe nur zwei Situationen gefunden, in denen getBean() erforderlich war:

Andere haben die Verwendung von getBean() in main() erwähnt, um die "Haupt"-Bean für ein eigenständiges Programm abzurufen.

Eine weitere Verwendung von getBean() habe ich in Situationen gefunden, in denen eine interaktive Benutzerkonfiguration die Bean-Zusammensetzung für eine bestimmte Situation bestimmt. So durchläuft beispielsweise ein Teil des Boot-Systems eine Datenbanktabelle mit Hilfe von getBean() mit einer scope='prototype' Bean-Definition und setzt dann zusätzliche Eigenschaften. Vermutlich gibt es eine Benutzeroberfläche, die die Datenbanktabelle anpasst, was freundlicher wäre als der Versuch, die Anwendungskontext-XML (neu) zu schreiben.

Answer 3

Es gibt jedoch immer noch Fälle, in denen Sie das Service Locator-Muster benötigen. Zum Beispiel habe ich eine Controller-Bean, dieser Controller könnte einige Standard-Service-Beans haben, die durch Konfiguration in Abhängigkeit injiziert werden können. Es könnte aber auch viele zusätzliche oder neue Dienste geben, die dieser Controller jetzt oder später aufrufen kann, die dann den Service Locator benötigen, um die Service Beans abzurufen.

Answer 4

Sie sollten verwenden: ConfigurableApplicationContext statt für ApplicationContext