อะไรคือเหตุผลเบื้องหลังพฤติกรรม ioc นี้ (แก้ไขด้วยองค์ประกอบที่ลงทะเบียนหลายรายการ)

ดูเหมือนเป็นแนวทางมาตรฐานสำหรับ ioc เมื่อได้รับสถานการณ์เช่น (C# windsor):

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

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

เป็นไปได้ว่าเมื่อแก้ไขส่วนประกอบ ILogger ที่ลงทะเบียนครั้งแรก (HttpLogger ในกรณีนี้) เป็นตัวเลือกเดียวสำหรับการแก้ไข จากนั้น ioc จะค้นหาตัวสร้างที่ 'อ้วนที่สุด' ที่สามารถทำได้โดยที่เชื่อว่าสามารถแก้ไขการอ้างอิงทั้งหมดได้

อย่างไรก็ตาม อาจเป็นไปได้ว่า ioc ไม่สามารถแก้ไขการขึ้นต่อกันสำหรับตัวบันทึกแรกได้ และจะกลับมาพร้อมกับปัญหาการแก้ไข อาจเป็นกรณีที่ SmtpLogger สามารถแก้ไขได้หาก ioc พยายามแล้ว

แล้วอะไรคือเหตุผลในการใช้บริการที่ลงทะเบียนครั้งแรกในฐานะผู้สมัครเท่านั้น? ดูเหมือนว่าความไม่แน่นอนว่าคุณจะได้รับประเภทใดนั้นเป็นข้อโต้แย้ง แต่แล้ว ioc ก็ถูกปล่อยให้รับผิดชอบว่าคอนสตรัคเตอร์ตัวไหนที่ใช้ต่อไป

ดังนั้นทำไมไม่เลือกจากตัวสร้างทุกประเภทที่เกี่ยวข้องทั้งหมด และเริ่มพยายามแก้ไขจากตัวสร้างที่อ้วนที่สุดลง (ผู้ไม่เชื่อเรื่องพระเจ้าของประเภทจริง)

นี่อาจมีคำตอบที่ชัดเจนมาก แต่จริงๆ แล้วฉันไม่รู้

ขอบคุณล่วงหน้าสตีเฟน


person meandmycode    schedule 04.09.2009    source แหล่งที่มา
comment
สวัสดี. กรุณาฉันสงสัยว่าภาษาการเขียนโค้ดที่คุณใช้ในตัวอย่างของคุณคืออะไร?   -  person KLE    schedule 05.09.2009
comment
ภาษาตัวอย่างคือ C# และคอนเทนเนอร์ตัวอย่างคือ Castle Windsor   -  person meandmycode    schedule 05.09.2009


คำตอบ (1)


เหตุผลก็คือผลกระทบต่อความซับซ้อนในการดำเนินการ

เมื่อพฤติกรรมประเภทนี้ถูกปฏิบัติ มันจะทำงานแบบวนซ้ำ เช่น การพิจารณาว่าการขึ้นต่อกันของตัวบันทึกตัวใดตัวหนึ่งสามารถตอบสนองได้หรือไม่นั้น จำเป็นต้องพิจารณาการขึ้นต่อกันของ มัน ทั้งหมดและอื่นๆ

การทำสิ่งนี้อย่างมีประสิทธิภาพเป็นเรื่องยาก และเพิ่มความซับซ้อนอย่างมากให้กับคอนเทนเนอร์และประสบการณ์การแก้ไขจุดบกพร่อง

MEF แม้จะไม่ได้เป็นคอนเทนเนอร์ IoC อย่างเคร่งครัด แต่ก็ทำในลักษณะคล้ายกับที่คุณแนะนำ ซึ่งเป็นส่วนหนึ่งของพฤติกรรมการจัดองค์ประกอบที่เสถียร ซึ่งเป็นสิ่งที่เราเรียกว่า 'การปฏิเสธ'

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

ในสถานการณ์ปลั๊กอินที่มีไดนามิกสูง การปฏิเสธจะมีประโยชน์อย่างมาก ในสถานการณ์ที่ Windsor, Autofac ฯลฯ กำลังกำหนดเป้าหมาย ความพยายามที่เพิ่มเข้ามาไม่ได้ให้ผลมากนัก

person Nicholas Blumhardt    schedule 05.09.2009
comment
อ่า ฮ่า! ฉันเริ่มคิดว่าจะไม่ได้รับคำตอบ จากนั้นฉันก็ได้รับคำตอบจากปรมาจารย์ ioc :) ขอบคุณมาก! - person meandmycode; 06.09.2009
comment
นอกจากนี้คุณต้องการที่จะล้มเหลวอย่างรวดเร็ว หากคุณเปลี่ยนแปลงบางสิ่งที่ทำให้ส่วนประกอบแรกไม่สามารถแก้ไขได้ คุณต้องการทราบทันที ไม่ใช่หลังจากเกิดข้อขัดข้องที่ไซต์ไคลเอนต์และคุณได้รับสายโกรธว่าส่วนประกอบดังกล่าวหยุดทำงานเป็นเวลา 2 ชั่วโมงโดยไม่มีใครสังเกตเห็น เพราะตอนนี้ IHttpLogger ถูกฉีดเข้าไปแทน ISMSLogger - person Krzysztof Kozmic; 09.09.2009
comment
ฉันเข้าใจ แม้ว่าจะคล้ายกับวิธีที่ฉันถือว่า MEF จัดการสิ่งนี้ แต่ฉันขอยืนยันว่ามีวิธีการแก้ปัญหาที่ส่งคืนรายละเอียดการแก้ปัญหา ไม่ใช่แค่อินสแตนซ์บริการ และอาจบันทึกปัญหาการแก้ไขในลักษณะที่ตัดกันมากขึ้น - person meandmycode; 19.09.2009