คำถามติดแท็ก ioc-containers

ฉันเข้าใจว่าการพึ่งพาการสร้างอินสแตนซ์โดยตรงภายในชั้นเรียนถือเป็นการฝึกฝนที่ไม่ดี สิ่งนี้เหมาะสมที่จะทำทุกอย่างให้แน่นเพื่อทดสอบอย่างหนัก เฟรมเวิร์กเกือบทั้งหมดที่ฉันเจอดูเหมือนว่าจะชอบการฉีดแบบพึ่งพากับคอนเทนเนอร์มากกว่าโดยใช้ตัวระบุบริการ ทั้งคู่ดูเหมือนจะประสบความสำเร็จในสิ่งเดียวกันโดยอนุญาตให้โปรแกรมเมอร์ระบุวัตถุที่ควรส่งคืนเมื่อคลาสต้องการการพึ่งพา ความแตกต่างระหว่างสองคืออะไร ทำไมฉันถึงเลือกอันหนึ่งมากกว่าอีกอัน?

107 dependency-injection  ioc-containers  service-locator 

คำinvertหรือcontrolไม่ได้ใช้เลยเพื่อกำหนด Inversion of Control ในคำจำกัดความที่ฉันเคยเห็น คำนิยาม วิกิพีเดีย การผกผันของการควบคุม (IoC) เป็นเทคนิคการเขียนโปรแกรมแสดงไว้ที่นี่ในแง่ของการเขียนโปรแกรมเชิงวัตถุซึ่งการเชื่อมต่อวัตถุถูกผูกไว้ในเวลาทำงานโดยวัตถุประกอบและโดยทั่วไปจะไม่รู้จักในเวลารวบรวมโดยใช้การวิเคราะห์แบบคงที่ ~ http://en.wikipedia.org/wiki/Inversion_of_control Martin Fowler การผกผันของการควบคุมเป็นรูปแบบทั่วไปในชุมชน Java ที่ช่วยให้สายไฟภาชนะบรรจุที่มีน้ำหนักเบาหรือประกอบชิ้นส่วนจากโครงการที่แตกต่างกันในการประยุกต์ใช้เหนียว ~ อิงจาก http://www.martinfowler.com/articles/inject.html (reworded) แล้วทำไม Inversion of Control ถึงชื่อว่า Inversion of Control? การควบคุมแบบใดที่กลับด้านและเกิดอะไรขึ้น มีวิธีกำหนด Inversion of Control โดยใช้คำศัพท์: กลับหัวและควบคุม ?

98 naming  definition  ioc-containers  inversion-of-control 

การใช้การพึ่งพาการฉีดและผกผันของการควบคุมควรลบการเกิดขึ้นทั้งหมดของnewคำหลัก "" ออกจากรหัสของคุณหรือไม่? ในคำอื่น ๆ ทุกวัตถุ / การพึ่งพาไม่ว่าจะง่ายหรืออายุสั้นเป็น "ลงทะเบียน" ในภาชนะ IoC ของคุณและฉีดเข้าไปในวิธีการ / ชั้นเรียนที่ต้องใช้พวกเขา? ถ้าไม่คุณจะวาดเส้นไหนระหว่างการพึ่งพา / วัตถุที่ลงทะเบียนในคอนเทนเนอร์ IoC เทียบกับสิ่งที่ได้รับการสร้าง "ในบรรทัด" เป็นข้อมูลอ้างอิงที่เป็นรูปธรรมผ่านnewคำหลัก?

21 .net  dependency-injection  ioc-containers 

ฉันใช้คอนเทนเนอร์ IoC (Castle.Windsor, Autofac, MEF และอื่น ๆ ) สำหรับ. Net ในหลายโครงการ ฉันพบว่าพวกเขามักจะถูกทารุณกรรมบ่อยครั้งและส่งเสริมการปฏิบัติที่ไม่ดี มีแนวทางปฏิบัติที่กำหนดไว้สำหรับการใช้คอนเทนเนอร์ IoC โดยเฉพาะอย่างยิ่งเมื่อมีการจัดทำแพลตฟอร์ม / กรอบงาน เป้าหมายของฉันในฐานะนักเขียนเฟรมเวิร์กคือการทำโค้ดให้ง่ายและใช้งานง่ายที่สุดเท่าที่จะทำได้ ฉันควรเขียนโค้ดหนึ่งบรรทัดเพื่อสร้างออบเจ็กต์มากกว่าสิบหรือแม้แต่แค่สอง ตัวอย่างเช่นโค้ดสองสามกลิ่นที่ฉันสังเกตเห็นและไม่มีคำแนะนำที่ดีในการ: พารามิเตอร์จำนวนมาก (> 5) สำหรับตัวสร้าง การสร้างบริการมีความซับซ้อน การพึ่งพาทั้งหมดจะถูกฉีดผ่านทางคอนสตรัคเตอร์ - แม้ว่าจะมีความจริงที่ว่าส่วนประกอบนั้นเป็นทางเลือกที่หาได้ยาก (ยกเว้นในการทดสอบ) การขาดคลาสส่วนตัวและภายใน อันนี้อาจเป็นข้อ จำกัด เฉพาะของการใช้ C # และ Silverlight แต่ฉันสนใจที่จะแก้ไขมันอย่างไร เป็นการยากที่จะบอกว่าอินเตอร์เฟสเฟรมเวิร์กคืออะไรถ้าคลาสทั้งหมดเป็นแบบสาธารณะ มันช่วยให้ฉันเข้าถึงชิ้นส่วนส่วนตัวที่ฉันไม่ควรแตะ เชื่อมวงจรชีวิตของวัตถุกับคอนเทนเนอร์ IoC มันมักจะยากที่จะสร้างการอ้างอิงที่จำเป็นในการสร้างวัตถุ วงจรชีวิตของวัตถุได้รับการจัดการบ่อยเกินไปโดยกรอบงาน IoC ฉันเห็นโปรเจ็กต์ที่ชั้นเรียนส่วนใหญ่ลงทะเบียนเป็นซิงเกิลตัน คุณขาดการควบคุมอย่างชัดเจนและถูกบังคับให้จัดการ internals (มันเกี่ยวข้องกับประเด็นข้างต้นทุกชั้นเป็นสาธารณะและคุณต้องฉีดมัน) ตัวอย่างเช่น. …

18 .net  silverlight  dependency-injection  ioc-containers  inversion-of-control 

แม้จะมีความนิยม แต่มีหลักฐานเชิงประจักษ์ที่แสดงให้เห็นว่าการพึ่งพาการฉีด (และ / หรือการใช้ภาชนะ DI) ช่วยพูดลดจำนวนข้อผิดพลาดปรับปรุงการบำรุงรักษาหรือเพิ่มความเร็วการพัฒนาในโครงการซอฟต์แวร์ในชีวิตจริง?

18 design-patterns  dependency-injection  inversion-of-control  ioc-containers  evidence-based 

ฉันเห็นหลายแนะนำให้ใช้คอนเทนเนอร์ IoC ในรหัส แรงจูงใจนั้นง่าย ใช้รหัสฉีดพึ่งพาต่อไปนี้: class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest( std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency) ) : d_(d) { } }; TEST(UnitUnderTest, Example) { std::auto_ptr<Dependency> dep(new MockDependency); UnitUnderTest uut(dep); //Test here } เป็น: class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest() { d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency"))); } }; TEST(UnitUnderTest, Example) { …

17 dependency-injection  inversion-of-control  ioc-containers 

ฉันขอโทษถ้าสิ่งนี้ดูเหมือนจะเป็นคำถามที่เกิดขึ้นซ้ำแล้วซ้ำอีก แต่ทุกครั้งที่ฉันพบบทความเกี่ยวกับหัวข้อนั้นส่วนใหญ่จะพูดถึงว่า DI คืออะไร ดังนั้นฉันได้รับ DI แต่ฉันพยายามที่จะเข้าใจความต้องการภาชนะ IoC ซึ่งทุกคนดูเหมือนว่าจะเข้ามา จุดประสงค์ของคอนเทนเนอร์ IoC จริง ๆ แล้วเป็นเพียง "การแก้ไขอัตโนมัติ" การใช้งานที่เป็นรูปธรรมของการพึ่งพาหรือไม่ บางทีชั้นเรียนของฉันมีแนวโน้มที่จะไม่ได้ขึ้นต่อกันหลายครั้งและนั่นอาจเป็นเหตุผลว่าทำไมฉันไม่เห็นเรื่องใหญ่ แต่ฉันต้องการให้แน่ใจว่าฉันเข้าใจถึงประโยชน์ของภาชนะอย่างถูกต้อง โดยทั่วไปแล้วฉันแบ่งตรรกะทางธุรกิจของฉันออกเป็นคลาสที่อาจมีลักษณะเช่นนี้: public class SomeBusinessOperation { private readonly IDataRepository _repository; public SomeBusinessOperation(IDataRespository repository = null) { _repository = repository ?? new ConcreteRepository(); } public SomeType Run(SomeRequestType request) { // do work... var results …

15 c#  dependency-injection  inversion-of-control  ioc-containers 

กรอบการฉีดที่พึ่งพาเช่น Google Guice ให้แรงจูงใจต่อการใช้งาน (ที่มา ): ในการสร้างวัตถุคุณต้องสร้างการขึ้นต่อกันก่อน แต่ในการสร้างการพึ่งพาแต่ละครั้งคุณจำเป็นต้องมีการพึ่งพาและอื่น ๆ ดังนั้นเมื่อคุณสร้างวัตถุคุณจำเป็นต้องสร้างกราฟวัตถุ การสร้างกราฟวัตถุด้วยมือนั้นเป็นเรื่องยากสำหรับแรงงาน (... ) และทำให้การทดสอบเป็นเรื่องยาก แต่ฉันไม่ได้ซื้ออาร์กิวเมนต์นี้: แม้จะไม่มีกรอบการฉีดพึ่งพาฉันสามารถเขียนชั้นเรียนซึ่งทั้งง่ายต่อการ instantiate และสะดวกในการทดสอบ เช่นตัวอย่างจากหน้าแรงจูงใจของ Guiceสามารถเขียนใหม่ด้วยวิธีต่อไปนี้: class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = …

13 design-patterns  object-oriented  dependency-injection  ioc-containers 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันได้คิดเล็กน้อยเกี่ยวกับวิธีการฉีดพึ่งพาสามารถบูรณาการโดยตรงในภาษา C # เช่น ฉันคิดวิธีแก้ปัญหาที่เป็นไปได้ฉันอยากฟังความคิดเห็นของคุณ ฉันไม่ได้ใช้กรอบการฉีดพึ่งพาหลายคนดังนั้นอาจมีบางสิ่งที่ฉันมองเห็น อย่างไรก็ตามแนวคิดก็คือสามารถประกาศคุณสมบัติเป็น "ฉีดได้" โดยใช้คำหลัก เมื่อวัตถุถูกยกตัวอย่างและคุณสมบัตินั้นไม่ได้เริ่มต้นผ่านตัวสร้างหรือวัตถุเริ่มต้นมันขอตัวอย่างของคุณสมบัติประเภทนั้นจากบริการระดับโลกบางอย่าง ในทำนองเดียวกันคุณลงทะเบียนเครื่องจัดการสำหรับประเภทที่แตกต่างกับบริการนั้นเพื่อให้คุณสามารถยกตัวอย่างประเภททรัพย์สินที่ฉีด ข้อดีของการใช้สถาปัตยกรรม IMO ประเภทนี้คือความยืดหยุ่นและใช้งานง่าย ข้อเสียคืออาจมีค่าใช้จ่ายในการทำไฮไลต์บางครั้งในแต่ละครั้งที่คุณเริ่มชั้นเรียนที่มีการฉีด จากนั้นอีกครั้งนั่นเป็นเพียงปัญหาสำหรับคลาสที่รับอินสแตนซ์บ่อยในโซลูชันที่มีประสิทธิภาพสูงดังนั้นจึงไม่ควรเป็นปัญหามากนัก บางทีคุณอาจใช้โรงงานบางประเภทในกรณีเหล่านั้น ความคิดปัญหาคำถามความคิดที่ดีกว่า รหัส public class SomeClass { public SomeClass() { //implicit behavior if Animal is not set in constructor or initializer this.Animal = GlobalInjector.Get(this,typeof(Mammal)) } public injectable …

10 programming-languages  dependency-injection  ioc-containers 

ฉันกำลังพยายามคิดออกว่าจะใช้รีจิสตรี DIC / IoC ในการกำหนดค่าซอฟต์แวร์ของฉันและเมื่อใดที่จะใช้โรงงานพร้อมกับเหตุผลที่อยู่เบื้องหลังทั้งสองวิธี ฉันใช้ StructureMap เป็น DI container ของฉัน (DIC) ซึ่งง่ายต่อการกำหนดค่าโดยใช้การลงทะเบียน ใน DIC จริงวัตถุที่ลงทะเบียนทั้งหมดเป็นแบบคงที่ในความรู้สึกที่ฉันไม่จำเป็นต้องเปลี่ยน / แลกเปลี่ยนการใช้งาน / อินสแตนซ์ที่รันไทม์เมื่อ DIC มีการกำหนดค่าและพวกเขาจะถูกกำหนดค่าใน DIC เป็น singletons อย่างไรก็ตามเนื่องจากซอฟต์แวร์ (SW) ของฉันจะทำงานในอุปกรณ์ต่าง ๆ ฉันจึงต้องเลือกรีจิสตรีเฉพาะอุปกรณ์ขึ้นอยู่กับอุปกรณ์ที่ SW ของฉันทำงานเพื่อกำหนดค่าฮาร์ดแวร์ให้เหมาะสม เนื่องจากการสร้างวัตถุบางอย่างของฉันต้องอ่านในไฟล์กำหนดค่าฉันจึงใช้โรงงานเพื่อส่งคืนอินสแตนซ์เหล่านี้ไปยัง DIC เพื่อแยกการอ่านการกำหนดค่าออกจากการสร้างวัตถุ ฉันลงทะเบียนตัวรับสัญญาณจากโรงงานใน DIC สำหรับประเภทปลั๊กอินที่เกี่ยวข้อง ตอนนี้บอกว่าฉันมีประเภทปลั๊กอินที่IMotorมีรูปแบบที่เป็นรูปธรรมMotor1และMotor2ซึ่งควรได้รับการจัดการโดยโรงงาน ขณะนี้มีสองวิธีที่ฉันสามารถตัดสินใจได้ว่าจะกำหนดค่าอุปกรณ์ของฉันอย่างไร: ฉันผ่านข้อมูลเกี่ยวกับอุปกรณ์ที่ว่า SW กำลังทำงานอยู่บนไปMotorFactoryและจะส่งกลับมอเตอร์ที่ถูกต้องอย่างใดอย่างหนึ่งหรือMotor1 Motor2ในกรณีนี้ตรรกะในการตัดสินใจอยู่ภายในโรงงาน ผมกำหนดค่าไอซีตามไปยังอุปกรณ์ที่ทำงานอยู่ในและสร้างโรงงานที่สองMotor1FactoryและMotor2Factoryที่หนึ่งสร้างและอื่น ๆMotor1 Motor2ในกรณีนี้ผมจะมีที่แตกต่างกันสำหรับรายการรีจิสทรีIMotorในการลงทะเบียนเฉพาะอุปกรณ์ที่ใช้อย่างใดอย่างหนึ่งหรือMotor1FactoryMotor2Factory ตอนนี้คำถามของฉันคือ: หนึ่งในสองวิธีนี้เป็นที่นิยมและทำไม สำหรับฉันดูเหมือนว่ากรณีแรกจะไม่ตรงไปข้างหน้าและซับซ้อนเนื่องจากฉันกระจายตรรกะที่ตัดสินใจประเภทที่จะยกตัวอย่างทั่วรหัสฐาน …

9 configuration  factory  ioc-containers