คำถามติดแท็ก inversion-of-control

ฉันได้เห็นการอ้างอิงจำนวนมากของ Dependency Injection (DI) & Inversion Of Control (IOC) แต่ฉันไม่รู้จริง ๆ ว่ามีความแตกต่างระหว่างพวกเขาหรือไม่ ฉันต้องการเริ่มใช้หนึ่งหรือทั้งสองอย่าง แต่ฉันสับสนเล็กน้อยว่ามันแตกต่างกันอย่างไร

117 dependency-injection  inversion-of-control 

คำ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 

ฉันกำลังออกแบบระบบใหม่และฉันต้องการทราบว่าการควบคุมกลับกัน (IOC) คืออะไรและที่สำคัญเมื่อใช้ จะต้องมีการใช้งานกับอินเตอร์เฟสหรือสามารถทำได้กับคลาส?

64 design  design-patterns  inversion-of-control 

ฉันกำลังทำงานกับทีมที่หัวหน้าทีมเป็นผู้สนับสนุนหลักการการพัฒนาที่มั่นคง อย่างไรก็ตามเขาขาดประสบการณ์จำนวนมากในการนำซอฟต์แวร์ที่ซับซ้อนออกจากประตู เรามีสถานการณ์ที่เขาใช้ SRP กับสิ่งที่เคยเป็นฐานรหัสที่ซับซ้อนอยู่แล้วซึ่งตอนนี้มีการแยกส่วนสูงมากและยากที่จะเข้าใจและตรวจแก้จุดบกพร่อง ตอนนี้เรามีปัญหาไม่เพียง แต่กับการกระจายตัวของรหัส แต่ยังรวมถึงการห่อหุ้มเป็นวิธีการภายในชั้นเรียนที่อาจเป็นส่วนตัวหรือได้รับการป้องกันได้รับการพิจารณาเพื่อเป็นตัวแทนของ 'เหตุผลในการเปลี่ยนแปลง' และได้รับการสกัด ไม่สอดคล้องกับเป้าหมายการห่อหุ้มของแอปพลิเคชัน เรามีตัวสร้างคลาสที่ใช้พารามิเตอร์อินเทอร์เฟซมากกว่า 20 ตัวดังนั้นการลงทะเบียน IoC และการแก้ปัญหาของเราจึงกลายเป็นสัตว์ประหลาดในตัวของมันเอง ฉันต้องการทราบว่ามี 'refactor อยู่ห่างจาก SRP' หรือไม่ที่เราสามารถใช้เพื่อช่วยแก้ไขปัญหาเหล่านี้ได้ ฉันได้อ่านแล้วว่ามันไม่ได้เป็นการละเมิด SOLID ถ้าฉันสร้างคลาสที่ว่างเปล่าแบบหยาบจำนวนมากที่ 'ห่อ' คลาสที่เกี่ยวข้องอย่างใกล้ชิดเพื่อให้เข้าถึงจุดรวมการทำงานของจุดเดียว (เช่นการเลียนแบบน้อย ใช้งานคลาสมากเกินไป SRP) นอกจากนั้นฉันไม่สามารถคิดถึงวิธีแก้ปัญหาที่จะช่วยให้เราสามารถดำเนินการต่อไปในการพัฒนาของเราในทางปฏิบัติในขณะที่ทำให้ทุกคนมีความสุข ข้อเสนอแนะใด ๆ

56 c#  wpf  inversion-of-control  single-responsibility 

วัตถุประสงค์ของ IOC Containers คืออะไร? เหตุผลที่รวมกันสามารถทำให้เป็นดังต่อไปนี้: เมื่อใช้หลักการพัฒนา OOP / SOLID การพึ่งพาการฉีดจะทำให้เกิดความยุ่งเหยิง ไม่ว่าคุณจะมีจุดเริ่มต้นระดับสูงสุดที่จัดการการพึ่งพาสำหรับหลายระดับต่ำกว่าตนเองและผ่านการอ้างอิงซ้ำผ่านการก่อสร้างซ้ำหรือคุณมีรหัสที่ซ้ำกันในรูปแบบโรงงาน / ผู้สร้างและอินเตอร์เฟสที่สร้างการพึ่งพาตามที่คุณต้องการ ไม่มีวิธี OOP / SOLID ในการดำเนินการนี้และมีรหัสสวยมาก หากข้อความก่อนหน้านั้นเป็นจริงแล้วตู้คอนเทนเนอร์ IOC จะทำอย่างไร เท่าที่ฉันรู้พวกเขาไม่ได้ใช้เทคนิคที่ไม่รู้จักบางอย่างที่ไม่สามารถทำได้ด้วยตนเอง DI ดังนั้นการอธิบายเพียงอย่างเดียวคือ IOC Containers ทำลายหลักการ OOP / SOLID โดยการใช้อ็อบเจกต์ส่วนตัวแบบคงที่ ตู้ IOC ทำลายหลักการต่อไปนี้หรือไม่? นี่เป็นคำถามจริงเนื่องจากฉันมีความเข้าใจที่ดี แต่มีความรู้สึกว่ามีคนอื่นมีความเข้าใจที่ดีขึ้น: การควบคุมขอบเขต ขอบเขตคือเหตุผลสำหรับเกือบทุกการตัดสินใจของฉันในการออกแบบรหัสของฉัน บล็อกท้องถิ่นโมดูลคงที่ / ทั่วโลก ขอบเขตควรชัดเจนมากที่สุดเท่าที่ระดับบล็อกและน้อยที่สุดที่คงที่ที่สุด คุณควรเห็นการประกาศการสร้างอินสแตนซ์และการสิ้นสุดวงจรชีวิต ฉันเชื่อมั่นในภาษาและ GC ในการจัดการขอบเขตตราบใดที่ฉันชัดเจนด้วย จากการวิจัยของฉันฉันพบว่า IOC Containers ตั้งค่าการพึ่งพาส่วนใหญ่หรือทั้งหมดเป็นแบบคงที่และควบคุมพวกมันผ่านการใช้งาน …

51 object-oriented  solid  inversion-of-control 

ฉันได้อ่านเพิ่มเติมเกี่ยวกับหลักการผกผันของการควบคุมและการพึ่งพาการฉีดเพื่อนำไปใช้และฉันค่อนข้างมั่นใจว่าฉันเข้าใจมัน ดูเหมือนว่าโดยทั่วไปแล้วจะพูดว่า 'อย่าประกาศให้อินสแตนซ์ของสมาชิกชั้นเรียนของคุณ' ในชั้นเรียน ' ค่อนข้างว่าอินสแตนซ์ควรจะถูกส่งผ่านและได้รับมอบหมายผ่านตัวสร้าง; 'ฉีด' เข้าสู่ชั้นเรียนจากแหล่งภายนอก ถ้ามันง่ายนี่มันน่าจะเป็นเหตุผลทำไมเราต้องใช้เฟรมเวิร์กเช่นสปริงหรือ guice ที่ใช้มันกับหมายเหตุประกอบ? ฉันขาดพื้นฐานบางอย่างที่นี่หรือไม่? ฉันกำลังดิ้นรนจริงๆที่จะเข้าใจว่าการใช้กรอบการฉีดพึ่งพาคืออะไร แก้ไข: เกี่ยวกับความซ้ำซ้อนที่เป็นไปได้ฉันเชื่อว่าคำถามของฉันไม่เหมือนใครเพราะถามเกี่ยวกับกรอบ DI โดยทั่วไปไม่ใช่เฉพาะฤดูใบไม้ผลิ Spring ไม่ได้เป็นเพียงกรอบ DI ดังนั้นจึงมีหลายเหตุผลที่บางคนต้องการใช้ Spring ที่ไม่เกี่ยวข้องกับ DI

42 dependency-injection  spring  inversion-of-control  google-guice 

ฉันต้องการใช้การฉีดพึ่งพาในแอพพลิเคชั่นที่ค่อนข้างใหญ่ แต่ไม่มีประสบการณ์ ฉันศึกษาแนวคิดและการใช้งาน IoC และหัวฉีดพึ่งพาบางอย่างเช่น Unity และ Ninject อย่างไรก็ตามมีสิ่งหนึ่งที่ทำให้ฉันหลุดพ้น ฉันจะจัดระเบียบการสร้างอินสแตนซ์ในแอปพลิเคชันของฉันได้อย่างไร สิ่งที่ฉันคิดคือฉันสามารถสร้างโรงงานเฉพาะไม่กี่แห่งซึ่งจะมีตรรกะในการสร้างวัตถุสำหรับชั้นเรียนเฉพาะบางประเภท โดยทั่วไปคลาสสแตติกที่มีเมธอดที่เรียกใช้เมธอด Ninject Get () ของอินสแตนซ์เคอร์เนลแบบสแตติกในคลาสนี้ มันจะเป็นวิธีที่ถูกต้องในการใช้งานการฉีดพึ่งพาในใบสมัครของฉันหรือฉันควรจะใช้มันตามหลักการอื่น ๆ ?

22 c#  .net  dependency-injection  inversion-of-control  ninject 

ฉันเป็นแฟนตัวยงของ DI / IOC มันเป็นเรื่องที่ยอดเยี่ยมสำหรับการจัดการ / การแยกตัวออกจากการพึ่งพาอย่างหนักและทำให้ชีวิตง่ายขึ้นเล็กน้อย อย่างไรก็ตามฉันมีด้ามจับเล็ก ๆ กับมันซึ่งฉันไม่แน่ใจว่าจะแก้ปัญหาได้อย่างไร แนวคิดพื้นฐานใน DI / IOC คือเมื่อวัตถุถูกสร้างอินสแตนซ์การอ้างอิงทั้งหมดจะถูกเติมไว้ล่วงหน้าภายใน Constructor อย่างไรก็ตาม IMHO มีพารามิเตอร์หลายประเภทสำหรับตัวสร้าง (โดยเฉพาะเมื่อวัตถุของคุณไม่เปลี่ยนรูป) การพึ่งพา (วัตถุที่จำเป็นสำหรับวัตถุของคุณในการทำงาน) การกำหนดค่า (ข้อมูลเกี่ยวกับสภาพแวดล้อมที่จำเป็นในการทำงาน) พารามิเตอร์ (ข้อมูลที่ใช้งานได้) ฉันพบว่า IOC ทำงานได้ดีกับการอ้างอิง แต่ฉันยังคงพยายามหาวิธีที่ดีที่สุดในการจัดการกับอีกสองคน อย่างไรก็ตามเนื่องจากตัวสร้างถูกเรียกใช้เพื่อให้เรียกใช้งานโดยคอนเทนเนอร์ IOC ดูเหมือนว่าฉันต้องวางรายการเหล่านี้ลงในคอนเทนเนอร์ IOC ฉันต้องการทราบว่ากลยุทธ์ / รูปแบบการจ้างงานของผู้คนและข้อดีและข้อเสียที่พบ NB ฉันรู้ว่านี่เป็นคำถามที่เป็นอัตนัยและได้พยายามทำให้เป็นคำถามแบบอัตนัย "ดี" ตามแนวทางของ SE

18 design-patterns  configuration-management  inversion-of-control 

ฉันใช้คอนเทนเนอร์ 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 

บริบท: ฉันใช้ C # ฉันออกแบบชั้นเรียนและเพื่อแยกมันออกและทำให้การทดสอบหน่วยง่ายขึ้นฉันกำลังผ่านการพึ่งพาทั้งหมด มันไม่สร้างอินสแตนซ์ของวัตถุภายใน อย่างไรก็ตามแทนที่จะอ้างอิงอินเทอร์เฟซเพื่อรับข้อมูลที่ต้องการฉันขอให้อ้างอิงวัตถุประสงค์ทั่วไป Funcs ที่ส่งคืนข้อมูล / พฤติกรรมที่ต้องการ เมื่อฉันฉีดการพึ่งพาของฉันฉันสามารถทำได้ด้วยการแสดงออกแลมบ์ดา สำหรับฉันดูเหมือนว่าจะเป็นวิธีที่ดีกว่าเพราะฉันไม่ต้องล้อเลียนเรื่องน่าเบื่อใด ๆ ระหว่างการทดสอบหน่วย นอกจากนี้หากการดำเนินการโดยรอบมีการเปลี่ยนแปลงพื้นฐานฉันจะต้องเปลี่ยนระดับโรงงานเท่านั้น ไม่มีการเปลี่ยนแปลงในชั้นเรียนที่มีตรรกะจะต้อง อย่างไรก็ตามฉันไม่เคยเห็น IoC ทำแบบนี้มาก่อนซึ่งทำให้ฉันคิดว่าอาจมีข้อผิดพลาดที่อาจเกิดขึ้น สิ่งเดียวที่ฉันคิดได้คือความไม่ลงรอยกันเล็กน้อยกับ C # รุ่นก่อนหน้าซึ่งไม่ได้กำหนด Func และนี่ไม่ใช่ปัญหาในกรณีของฉัน มีปัญหาใด ๆ หรือไม่ที่มีการใช้งานผู้รับมอบสิทธิ์ทั่วไป / ฟังก์ชั่นการสั่งซื้อที่สูงขึ้นเช่น Func สำหรับ IoC ซึ่งตรงข้ามกับส่วนต่อประสานที่เฉพาะเจาะจงมากขึ้น?

15 architecture  interfaces  inversion-of-control  delegates 

ฉันได้ทำการค้นคว้าเพิ่มเติมเกี่ยวกับการเขียนโปรแกรม "ที่เป็นระเบียบ" เมื่อเร็ว ๆ นี้และฉันได้เรียนรู้ว่าฉันควรจะเขียนโปรแกรมไปยังอินเทอร์เฟซไม่ใช่การใช้งาน โดยที่ในใจมันจะดีกว่าหรือไม่ที่จะ "ร่าง" โครงการในส่วนต่อประสานก่อนที่จะเขียนการนำไปปฏิบัติในที่ที่เป็นไปได้? และถ้าเป็นกรณีนี้ในกรณีของการใช้ไลบรารี่ของบุคคลที่สาม (เช่น Lidgren) ฉันควรจะห่อมันไว้ในส่วนต่อประสานและแก้ไขมันผ่านคอนเทนเนอร์ IOC หรือไม่

14 c#  design  interfaces  third-party-libraries  inversion-of-control 

ฉันเรียนรู้ที่จะพัฒนา Test Driven Development (TDD), Dependency Injection (DI) และ Inversion of Control (IoC) ทั้งหมดในเวลาเดียวกัน เมื่อฉันเขียนรหัสโดยใช้ TDD ฉันมักจะจบลงด้วยการใช้ DI ใน Constructor ของชั้นเรียน ฉันสงสัยว่านี่เป็นเพราะฉันเรียนรู้ที่จะทำ TDD หรือถ้านี่เป็นผลข้างเคียงตามธรรมชาติของ TDD ดังนั้นคำถามของฉันคือ: ทำตามหลักการของ TDD และการทดสอบหน่วยการเขียนที่ไม่ได้ขึ้นอยู่กับบริการภายนอกที่นำไปสู่ ​​DI อย่างหลีกเลี่ยงไม่?

14 tdd  dependency-injection  inversion-of-control