Vorwort
In diesem Artikel wird hauptsächlich den relevanten Inhalt über die Suche (Methodeninjektion) im Frühjahr eingeführt. Es wird für Ihre Referenz und Ihr Lernen geteilt. Ich werde unten nicht viel sagen. Schauen wir uns die detaillierte Einführung gemeinsam an:
Dies kann bei der Verwendung des Frühlings passieren: Eine Singleton-Bohne hängt von einer anderen Nicht-Singleton-Bohne ab. Wenn Sie einfach eine automatische Assembly verwenden, um Abhängigkeiten zu injizieren, können einige Probleme auftreten, wie unten gezeigt:
Klasse A für Singleton
@ComponentPublic Classa {@autowired Private classB classB; public void printClass () {System.out.println ("Dies ist Klasse A:" + this); classb.printclass (); }}Klasse B für Nicht-Single
@Component@scope (value = scope_prototype) public class classB {public void printClass () {System.out.println ("Dies ist Klasse B:" + this); }} Hier adoptiert Klasse A den Standard -Singleton -Bereich und stützt sich auf Klasse B. Der Umfang der Klasse B ist der Prototyp, daher ist es kein Singleton. Zu diesem Zeitpunkt können Sie das Problem des Schreibens wie diesen sehen, nachdem Sie einen Test ausgeführt haben:
@Runwith (springrunner.class) @ContextConfiguration (classes = {classa.class, classb.class}) öffentliche Klasse MyTest {@autowired private classa classa; @Test public void simpleetest () {für (int i = 0; i <3; i ++) {classa.printClass (); }}}Das Ausgangsergebnis ist:
Dies ist Klasse A: Classa@282003E1
Dies ist Klasse B: classB@7fad8c79
Dies ist Klasse A: Classa@282003E1
Dies ist Klasse B: classB@7fad8c79
Dies ist Klasse A: Classa@282003E1
Dies ist Klasse B: classB@7fad8c79
Wie Sie sehen können, ist der Hash -Code beider Klassen in den drei Ausgängen gleich. Es ist verständlich, dass der Wert der Klasse A unverändert bleibt, weil es sich um einen Singleton handelt, aber der Umfang der Klasse B ist ein Prototyp, hält aber auch den Hash -Code unverändert, was zu einem Singleton geworden zu sein scheint?
Der Grund für diese Situation ist, dass der Umfang der Klasse A der Standard -Singleton ist, sodass der Kontext nur einmal die Bohne der Klasse A erstellt. Daher besteht nur eine Chance, Abhängigkeiten zu injizieren, und der Container kann die Klasse A nicht jedes Mal mit einer neuen Klasse B anbieten.
Nicht so gute Lösung
Um das obige Problem zu lösen, können Sie einige Änderungen an der Klasse A vornehmen, um applicationContextaware zu implementieren.
@ComponentPublic class Classa implementiert applicationContextaware {private applicationContext applicationContext; public void printClass () {System.out.println ("Dies ist Klasse A:" + this); getClassB (). Druckklasse (); } public classB getClassB () {return applicationContext.getbean (classB.class); } public void setApplicationContext (ApplicationContext applicationContext) löst beansexception {this.applicationContext = ApplicationContext; }}Auf diese Weise können Sie jedes Mal, wenn Sie zu Klasse B gehen müssen, manuell eine neue Bohne im Kontext finden. Nachdem ich einen weiteren Test ausgeführt habe, habe ich die folgende Ausgabe erhalten:
Dies ist Klasse A: com.devhao.classa@4df828d7
Dies ist Klasse B: com.devhao.classb@31206beb
Dies ist Klasse A: com.devhao.classa@4df828d7
Dies ist Klasse B: com.devhao.classb@3e77a1ed
Dies ist Klasse A: com.devhao.classa@4df828d7
Dies ist Klasse B: com.devhao.classb@3ffcd140
Sie können sehen, dass der Hash -Code der Klasse A in den drei Ausgängen unverändert bleibt, während die Klasse B jedes Mal unterschiedlich ist, was zeigt, dass das Problem gelöst wurde und die neue Instanz jedes Mal verwendet wird, wenn er aufgerufen wird.
Diese Schreibmethode ist jedoch stark mit dem Frühling verbunden, und der Frühling bietet eine weitere Möglichkeit, die Invasivität zu verringern.
@Nachschlagen
Spring bietet eine Annotation namens @lookup, eine Annotation, die auf der Methode funktioniert. Die von ihm gekennzeichnete Methode wird überschrieben. Anschließend ruft der Container nach dem Typ seines Rückgabewerts die Methode getBean () des Beanfaktoriums auf, um eine Bohne zurückzugeben.
@ComponentPublic Classa {public void printClass () {System.out.println ("Dies ist Klasse A:" + this); getClassB (). Druckklasse (); } @Lookup public classB getClassB () {return null; }} Es kann gefunden werden, dass es viel einfacher und nicht mehr stark mit der Feder gepaart ist. Wenn Sie den Test erneut ausführen, können Sie immer noch die richtige Ausgabe erhalten.
Der Rückgabewert der kommentierten Methode ist nicht mehr wichtig, da der Container dynamisch eine Unterklasse erzeugt und dann die kommentierte Methode umschreibt/implementiert, und die Unterklasse -Methode wird schließlich aufgerufen.
Die verwendete @lookup -Methode muss der folgenden Signatur entsprechen:
<public | geschützt> [Abstract] <Return-Type> theThodName (No-Argumente);
Zusammenfassen
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Referenzwert für das Studium oder die Arbeit eines jeden hat. Wenn Sie Fragen haben, können Sie eine Nachricht zur Kommunikation überlassen. Vielen Dank für Ihre Unterstützung bei Wulin.com.