Kata pengantar
Artikel ini terutama memperkenalkan konten yang relevan tentang pencarian (injeksi metode) di musim semi. Ini dibagikan untuk referensi dan pembelajaran Anda. Saya tidak akan mengatakan banyak hal di bawah. Mari kita lihat perkenalan terperinci bersama -sama:
Ini mungkin terjadi saat menggunakan Spring: One Singleton Bean tergantung pada kacang non-singleton lainnya. Jika Anda cukup menggunakan Auto-Assembly untuk menyuntikkan dependensi, beberapa masalah mungkin muncul, seperti yang ditunjukkan di bawah ini:
Kelas A untuk Singleton
@ComponentPublic Class classA {@Autowired private classb classb; public void printClass () {System.out.println ("Ini adalah kelas A:" + ini); classb.printclass (); }}Kelas B untuk non-single
@Component@scope (value = scope_prototype) class kelas publik {public void printClass () {System.out.println ("This is Class B:" + this); }} Di sini Kelas A mengadopsi ruang lingkup singleton default dan bergantung pada Kelas B. Lingkup Kelas B adalah prototipe, jadi ini bukan singleton. Saat ini, Anda dapat melihat masalah menulis seperti ini setelah menjalankan tes:
@Runwith (springrunner.class) @contextConfiguration (class = {classa.class, classb.class}) kelas publik mytest {@Autowired private classA classA; @Test public void sederhana () {for (int i = 0; i <3; i ++) {classa.printclass (); }}}Hasil outputnya adalah:
Ini adalah kelas A: classa@282003e1
Ini adalah kelas B: classb@7fad8c79
Ini adalah kelas A: classa@282003e1
Ini adalah kelas B: classb@7fad8c79
Ini adalah kelas A: classa@282003e1
Ini adalah kelas B: classb@7fad8c79
Seperti yang Anda lihat, kode hash dari kedua kelas adalah sama dalam tiga output. Dapat dimengerti bahwa nilai Kelas A tetap tidak berubah karena itu adalah singleton, tetapi ruang lingkup Kelas B adalah prototipe tetapi juga menjaga kode hash tidak berubah, yang tampaknya telah menjadi singleton?
Alasan untuk situasi ini adalah bahwa ruang lingkup Kelas A adalah singleton default, sehingga konteksnya hanya akan membuat kacang kelas A sekali, jadi hanya ada satu kesempatan untuk menyuntikkan dependensi, dan wadah tidak dapat menyediakan Kelas A dengan Kelas B baru setiap saat.
Solusi yang tidak terlalu bagus
Untuk menyelesaikan masalah di atas, Anda dapat membuat beberapa modifikasi ke Kelas A untuk mengimplementasikan ApplicationContextAware.
@ComponentPublic Class ClassA mengimplementasikan ApplicationContextAware {private ApplicationContext ApplicationContext; public void printClass () {System.out.println ("Ini adalah kelas A:" + ini); getClassB (). printClass (); } public classb getClassB () {return applicationContext.getBean (classb.class); } public void setApplicationContext (ApplicationContext ApplicationContext) melempar BeansException {this.applicationContext = ApplicationContext; }}Dengan cara ini, Anda dapat secara manual menemukan kacang baru dalam konteks setiap kali Anda harus pergi ke Kelas B. Setelah menjalankan tes lain, saya mendapat output berikut:
Ini adalah kelas A: com.devhao.classa@4df828d7
Ini adalah kelas B: com.devhao.classb@31206beb
Ini adalah kelas A: com.devhao.classa@4df828d7
Ini adalah kelas B: com.devhao.classb@3e77a1ed
Ini adalah kelas A: com.devhao.classa@4df828d7
Ini adalah kelas B: com.devhao.classb@3ffcd140
Anda dapat melihat bahwa kode hash dari Kelas A tetap tidak berubah dalam tiga output, sedangkan Kelas B berbeda setiap kali, yang menunjukkan bahwa masalah telah diselesaikan dan instance baru digunakan setiap kali dipanggil.
Namun, metode penulisan ini sangat digabungkan dengan pegas, dan Spring menyediakan cara lain untuk mengurangi invasif.
@Lookup
Spring memberikan anotasi yang disebut @LookUp, yang merupakan anotasi yang berfungsi pada metode ini. Metode yang ditandai olehnya akan ditimpa. Kemudian, sesuai dengan jenis nilai pengembaliannya, wadah memanggil metode getbean () dari beanfactory untuk mengembalikan kacang.
@ComponentPublic Class classA {public void printClass () {System.out.println ("This is Class A:" + this); getClassB (). printClass (); } @Lookup Public ClassB getClassB () {return null; }} Dapat ditemukan bahwa itu jauh lebih sederhana dan tidak lagi digabungkan dengan pegas. Menjalankan tes lagi masih bisa mendapatkan output yang benar.
Nilai pengembalian metode beranotasi tidak lagi penting, karena wadah akan secara dinamis menghasilkan subkelas dan kemudian menulis ulang/mengimplementasikan metode beranotasi, dan metode subclass akhirnya dipanggil.
Metode @LookUp yang digunakan harus mematuhi tanda tangan berikut:
<Public | Protected> [Abstrak] <Setil-Type> ThemethodName (No-Arguments);
Meringkaskan
Di atas adalah seluruh konten artikel ini. Saya berharap konten artikel ini memiliki nilai referensi tertentu untuk studi atau pekerjaan semua orang. Jika Anda memiliki pertanyaan, Anda dapat meninggalkan pesan untuk berkomunikasi. Terima kasih atas dukungan Anda ke wulin.com.