Apa alasan di balik perilaku ioc ini (Selesaikan dengan beberapa komponen terdaftar)

Sepertinya pendekatan standar untuk ioc ketika diberikan skenario seperti (C# windsor):

container.AddComponent<ILogger, HttpLogger>();
container.AddComponent<ILogger, SmtpLogger>();

var logger = container.Resolve<ILogger>();

Apakah ketika menyelesaikan komponen, ILogger terdaftar pertama (dalam hal ini HttpLogger) adalah satu-satunya kandidat untuk resolusi, ioc kemudian akan menemukan konstruktor 'paling gemuk' yang diyakini dapat menyelesaikan semua dependensi.

Namun, mungkin ioc tidak dapat menyelesaikan ketergantungan untuk logger pertama, dan karenanya akan kembali dengan masalah resolusi, bisa jadi SmtpLogger BISA diselesaikan jika ioc mencobanya.

Lalu apa alasannya hanya menggunakan layanan terdaftar pertama sebagai kandidat? tampaknya ketidakpastian tipe mana yang akan Anda dapatkan adalah sebuah argumen, tetapi ioc tetap bertanggung jawab atas konstruktor mana yang digunakannya.

Jadi mengapa tidak memilih dari semua konstruktor dari semua tipe yang berlaku, dan mulai mencoba menyelesaikan dari konstruktor yang paling gemuk (agnostik dari tipe sebenarnya)?

Ini mungkin memiliki jawaban yang sangat jelas tapi sejujurnya saya tidak mengetahuinya.

Terima kasih sebelumnya, Stephen.


dependency-injection inversion-of-control behavior
person meandmycode    schedule 04.09.2009    source sumber
comment
Hai. Tolong, saya ingin tahu bahasa pengkodean apa yang Anda gunakan dalam contoh Anda?   -  person KLE    schedule 05.09.2009
comment
Bahasa contohnya adalah C#, dan wadah contohnya adalah Castle Windsor.   -  person meandmycode    schedule 05.09.2009

Jawaban (1)


arrow_upward
2
arrow_downward

Alasannya adalah pengaruhnya terhadap kompleksitas implementasi.

Ketika perilaku seperti ini diterapkan, ternyata bekerja secara rekursif, mis. untuk mengetahui apakah dependensi salah satu logger dapat dipenuhi, diperlukan penelusuran semua dependensi nya dan seterusnya.

Melakukan hal ini secara efisien itu sulit, dan menambah banyak kerumitan pada container dan pengalaman debugging.

MEF, meskipun bukan merupakan wadah IoC, melakukan hal ini dengan cara yang mirip dengan apa yang Anda sarankan - ini adalah bagian dari perilaku Komposisi Stabil, sesuatu yang kami sebut sebagai 'penolakan'.

http://blogs.msdn.com/nblumhardt/archive/2009/07/17/light-up-or-mef-optional-exports.aspx

Dalam skenario plug-in yang sangat dinamis, penolakan sangatlah berguna. Dalam skenario yang ditargetkan oleh Windsor, Autofac, dll., upaya tambahan tersebut tidak membuahkan hasil yang besar.

person Nicholas Blumhardt    schedule 05.09.2009
comment
Ah ha! baiklah saya mulai berpikir saya tidak akan mendapat jawaban, lalu saya mendapat jawaban dari master ioc :), terima kasih banyak! - person meandmycode; 06.09.2009
comment
Juga, Anda ingin gagal dengan cepat. Jika Anda mengubah sesuatu yang membuat komponen pertama tidak mungkin diselesaikan, Anda ingin segera mengetahuinya, bukan setelah terjadi kerusakan di situs klien dan Anda mendapat panggilan marah, bahwa komponen tersebut mati selama 2 jam tanpa ada yang menyadarinya, karena sekarang IHttpLogger disuntikkan alih-alih Pencatat ISMS - person Krzysztof Kozmic; 09.09.2009
comment
Saya mengerti, meskipun mirip dengan bagaimana saya berasumsi MEF menangani hal ini, saya berpendapat untuk memiliki metode resolusi yang mengembalikan rincian resolusi dan bukan hanya contoh layanan, dan berpotensi mencatat masalah resolusi dengan cara yang lebih lintas sektoral. - person meandmycode; 19.09.2009