Lange Zeit glaubte ich, dass eine "zentralisierte, deklarative Konfiguration" wie die XML-Dateien, die wir alle verwendet haben, einen Wert hat. Dann wurde mir klar, dass die meisten Inhalte in den Dateien keine Konfiguration waren - sie wurden nach der Entwicklung nie geändert. Dann wurde mir klar, dass "zentralisiert" nur in recht kleinen Systemen einen Wert hat - nur in kleinen Systemen können Sie jemals eine Konfigurationsdatei als Ganzes erstellen . Und was ist es wirklich wert, die Verkabelung als Ganzes zu verstehen, wenn dieselben "Verkabelungen" meist durch Abhängigkeiten im Code dupliziert werden? Das einzige, was ich behalten habe, sind Metadaten (Anmerkungen), die immer noch deklarativ sind. Diese ändern sich nie zur Laufzeit und sie sind nie "Konfigurations" -Daten, die jemand im laufenden Betrieb ändern wird - daher finde ich es schön, sie im Code zu behalten.
Ich verwende so oft ich kann eine vollautomatische Verkabelung. Ich liebe es. Ich werde nicht zum alten Frühling zurückkehren, wenn ich nicht mit vorgehaltener Waffe bedroht bin. Meine Gründe für den Vorzug @Autowiredhaben sich im Laufe der Zeit geändert.
Im Moment denke ich, dass der wichtigste Grund für die Verwendung von Autowiring darin besteht, dass es in Ihrem System eine Abstraktion weniger gibt, die Sie im Auge behalten müssen. Der "Bohnenname" ist praktisch weg. Es stellt sich heraus, dass der Bean-Name nur aufgrund von XML existiert. Eine vollständige Schicht abstrakter Indirektionen (bei denen Sie den Bohnennamen "foo" in die Bohnenleiste "bar" verdrahten würden) ist also verschwunden. Jetzt verdrahte ich die "Foo" -Schnittstelle direkt mit meiner Bean, und die Implementierung wird durch das Laufzeitprofil ausgewählt. Dadurch kann ich beim Nachverfolgen von Abhängigkeiten und Implementierungen mit Code arbeiten . Wenn ich eine automatisch verdrahtete Abhängigkeit in meinem Code sehe, kann ich einfach die Taste "Zur Implementierung gehen" in meiner IDE drücken und die Liste der bekannten Implementierungen wird angezeigt. In den meisten Fällen gibt es nur eine Implementierung und ich bin direkt in der Klasse. Können' Welche Implementierung wird verwendet? (Ich behaupte, dass das Gegenteil mit XML-Verkabelung der Wahrheit näher kommt - lustig, wie sich Ihre Perspektive ändert!)
Nun könnte man sagen, dass es nur eine sehr einfache Ebene ist, aber jede Abstraktionsebene, die wir unseren Systemen hinzufügen, erhöht die Komplexität. Ich glaube wirklich nicht, dass die XML jemals einem System, mit dem ich gearbeitet habe, einen echten Mehrwert verliehen hat.
Die meisten Systeme, mit denen ich jemals gearbeitet habe, haben nur eine Konfiguration der Produktionslaufzeitumgebung. Möglicherweise gibt es andere Konfigurationen zum Testen und so weiter.
Ich würde sagen, dass volles Autowiring der Rubin auf Schienen des Frühlings ist: Es umfasst die Vorstellung, dass es ein normales und allgemeines Verwendungsmuster gibt, dem die meisten Anwendungsfälle folgen. Mit der XML-Konfiguration erlauben Sie eine Menge konsistenter / inkonsistenter Konfigurationsverwendungen, die möglicherweise nicht beabsichtigt sind. Ich habe gesehen, dass so viele XML-Konfigurationen mit Inkonsistenzen über Bord gehen - wird sie zusammen mit dem Code überarbeitet? Dachte nicht. Gibt es diese Variationen aus einem Grund? Normalerweise nicht.
Wir verwenden in unserer Konfiguration kaum Qualifikationsmerkmale und haben andere Wege gefunden, um diese Situationen zu lösen. Dies ist ein klarer „Nachteil“ wir begegnen: Wir leicht die Art , wie wir Code geändert haben damit interact glatter zu machen autowiring: Ein Kunde Repository nicht mehr implementiert die generische Repository<Customer>Schnittstelle , aber wir machen eine Schnittstelle , CustomerRepositorydie erweitert Repository<Customer>. Manchmal gibt es auch ein oder zwei Tricks, wenn es um Unterklassen geht. Aber es weist uns normalerweise nur in Richtung einer stärkeren Eingabe, was meiner Meinung nach fast immer eine bessere Lösung ist.
Aber ja, Sie binden an einen bestimmten DI-Stil, den der Frühling meistens tut. Wir machen nicht einmal mehr öffentliche Setter für Abhängigkeiten (Sie könnten also argumentieren, dass wir in der Abteilung für Kapselung / Verstecken von Informationen +1 sind). Wir haben immer noch einige XML-Dateien in unserem System, aber die XML-Dateien enthalten im Grunde nur die Anomalien. Full Autowiring lässt sich gut in XML integrieren.
Das einzige, was wir jetzt brauchen, ist @Component, dass @Autowiredder Rest in einem JSR (wie JSR-250 ) enthalten ist, damit wir uns nicht an den Frühling binden müssen. Dies ist die Art und Weise, wie die Dinge in der Vergangenheit passiert sind (das java.util.concurrentZeug fällt mir ein), daher wäre ich nicht ganz überrascht, wenn dies erneut passieren würde.