คำถามติดแท็ก dependency-injection

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

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

ฉันทำงานในโครงการที่ใช้ (Spring) Dependency Injection สำหรับทุกสิ่งที่เป็นที่พึ่งของชั้นเรียน เราอยู่ในจุดที่ไฟล์การกำหนดค่าของ Spring โตขึ้นประมาณ 4,000 บรรทัด เมื่อไม่นานมานี้ฉันได้ดูหนึ่งในการพูดคุยของลุงบ็อบบน YouTube (น่าเสียดายที่ฉันไม่สามารถหาลิงก์ได้) ซึ่งเขาแนะนำให้ฉีดการพึ่งพาจากศูนย์กลางเพียงไม่กี่คู่ (เช่นโรงงานฐานข้อมูล ... ) ลงในองค์ประกอบหลักจากนั้น แจกจ่าย ข้อดีของวิธีนี้คือการแยกส่วนของ DI Framework จากแอปพลิเคชั่นส่วนใหญ่และทำให้ Spring config Cleaner เป็นโรงงานจะมีสิ่งที่อยู่ใน config ก่อนหน้านี้ ในทางตรงกันข้ามสิ่งนี้จะส่งผลให้เกิดการแพร่กระจายตรรกะการสร้างในคลาสโรงงานจำนวนมากและการทดสอบอาจยากขึ้น ดังนั้นคำถามของฉันคืออะไรคือข้อดีหรือข้อเสียอื่น ๆ ที่คุณเห็นในแนวทางหนึ่งหรืออีกวิธีหนึ่ง มีวิธีปฏิบัติที่ดีที่สุดหรือไม่? ขอบคุณมากสำหรับคำตอบของคุณ!

38 architecture  dependency-injection 

TD; DR: มีความสับสนเกี่ยวกับสิ่งที่ฉันถามดังนั้นนี่คือแนวคิดการขับขี่ที่อยู่เบื้องหลังคำถาม: ฉันมักจะตั้งคำถามว่ามันคืออะไร ฉันอาจไม่ได้พูดชัดแจ้ง แต่แรกเริ่ม แต่เจตนาได้เสมอ " เป็นโมดูลแยกแยกหลวมคู่ decoupled รหัส refactored " ช้าลงอย่างเห็นได้ชัดโดยธรรมชาติของตัวเองมากกว่า " เสาเดียวหน่วยทำทุกอย่างในที่เดียวหนึ่งไฟล์คู่แน่น " รหัส ส่วนที่เหลือเป็นเพียงรายละเอียดและอาการต่าง ๆ ของเรื่องนี้ที่ฉันเจอในตอนนี้หรือตอนนี้หรือจะในภายหลัง มันช้าลงอย่างแน่นอนในระดับหนึ่ง เช่นเดียวกับดิสก์ที่ไม่มีการดีแฟรกต์คุณต้องเลือกชิ้นส่วนจากทุกที่ มันช้ากว่า ได้อย่างแน่นอน แต่ฉันควรสนใจ และคำถามไม่ได้เกี่ยวกับ ... ไม่เกี่ยวกับการเพิ่มประสิทธิภาพขนาดเล็กการปรับให้เหมาะสมก่อนวัยและอื่น ๆ มันไม่เกี่ยวกับ "เพิ่มประสิทธิภาพส่วนนี้หรือส่วนที่ตาย" ถ้าเช่นนั้นจะเป็นอะไร เป็นเรื่องเกี่ยวกับระเบียบวิธีและเทคนิคโดยรวมและวิธีคิดเกี่ยวกับการเขียนโค้ดที่เกิดขึ้นเมื่อเวลาผ่านไป: "ฉีดรหัสนี้ในชั้นเรียนของคุณเป็นการพึ่งพา" "เขียนหนึ่งไฟล์ต่อคลาส" "แยกมุมมองของคุณออกจากฐานข้อมูลตัวควบคุมโดเมน" อย่าเขียน codeblock สปาเก็ตตี้ที่เป็นเนื้อเดียวกัน แต่เขียนส่วนประกอบแยกส่วนจำนวนมากที่ทำงานร่วมกัน มันเกี่ยวกับวิธีการและรูปแบบของรหัสที่ปัจจุบัน - ภายในทศวรรษนี้ - เห็นและสนับสนุนในกรอบการทำงานส่วนใหญ่ที่สนับสนุนการประชุมส่งต่อผ่านชุมชน มันเป็นการเปลี่ยนความคิดจาก 'monolithic blocks' เป็น …

35 object-oriented  performance  refactoring  dependency-injection 

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

32 dependency-injection  coupling 

เมื่อฉันใช้ IoC Container ในโปรเจ็กต์สุดท้ายของฉันฉันได้จบด้วยหน่วยงานโลหิตจางและตรรกะทางธุรกิจส่วนใหญ่ของฉันในบริการไร้สัญชาติ ฉันเคยเห็นโปรเจ็กต์ที่เขียนโดยนักพัฒนาคนอื่น ๆ ที่ใช้ "Inversion of Control" และพวกเขามักจะเป็น "Anemic" เนื่องจาก "Anemic Domain Model" เป็นรูปแบบต่อต้านจึงเป็นไปได้หรือไม่ที่จะใช้ IoC และ Rich Domain เป็นตัวอย่างที่ดีของพวกเขาโครงการโอเพนซอร์สที่ทำเช่นนั้น?

32 dependency-injection 

ฉันได้ใช้การพึ่งพาการฉีดในฤดูใบไม้ผลิมาระยะหนึ่งแล้วและฉันเข้าใจว่ามันทำงานอย่างไรและข้อดีและข้อเสียของการใช้มันคืออะไร อย่างไรก็ตามเมื่อฉันสร้างคลาสใหม่ฉันมักจะสงสัย - คลาสนี้ควรจัดการโดย Spring IOC Container หรือไม่ และฉันไม่ต้องการพูดถึงความแตกต่างระหว่างคำอธิบายประกอบ @Autowired, การกำหนดค่า XML, การฉีด setter, การฉีดคอนสตรัคเตอร์ ฯลฯ คำถามของฉันคือคำถามทั่วไป สมมติว่าเรามีบริการที่มีตัวแปลง: @Service public class Service { @Autowired private Repository repository; @Autowired private Converter converter; public List<CarDto> getAllCars() { List<Car> cars = repository.findAll(); return converter.mapToDto(cars); } } @Component public class Converter { public CarDto …

32 java  dependency-injection  spring 

มีกรอบนี้ที่ฉันช่วยออกแบบ มีงานทั่วไปบางอย่างที่ควรทำโดยใช้ส่วนประกอบทั่วไป ได้แก่ การบันทึกการแคชและการเพิ่มเหตุการณ์โดยเฉพาะ ฉันไม่แน่ใจว่าจะใช้การฉีดแบบพึ่งพาหรือไม่และแนะนำส่วนประกอบเหล่านี้ทั้งหมดให้กับแต่ละบริการ (เช่นคุณสมบัติ) หรือควรฉันมีข้อมูลเมตาบางประเภทที่วางไว้เหนือแต่ละวิธีของบริการของฉันและใช้การสกัดกั้นเพื่อทำงานทั่วไปเหล่านี้ ? นี่คือตัวอย่างของทั้งคู่: ฉีด: public class MyService { public ILoggingService Logger { get; set; } public IEventBroker EventBroker { get; set; } public ICacheService Cache { get; set; } public void DoSomething() { Logger.Log(myMessage); EventBroker.Publish<EventType>(); Cache.Add(myObject); } } และนี่คือรุ่นอื่น ๆ : การสกัดกั้น: public class …

28 c#  dependency-injection 

ฉันค่อนข้างสบายใจกับการฉีดแบบพึ่งพาโดยใช้ NInject ใน MVC3 ในขณะที่ทำงานในแอปพลิเคชัน MVC3 ฉันได้พัฒนา Factory Creation Factory แบบกำหนดเองโดยใช้ NInject ดังนั้นคอนโทรลเลอร์ใด ๆ ที่สร้างขึ้นจะมีการขึ้นต่อกันของมันผ่านทาง Factory Controller นี้ ตอนนี้ฉันเริ่มพัฒนาแอพพลิเคชัน windows ฉันต้องการใช้ Application Wide Dependency Injection เช่นวัตถุทุกชิ้นจะต้องสร้างผ่าน NInject เพื่อให้ง่ายต่อการทดสอบหน่วย โปรดแนะนำฉันเพื่อให้แน่ใจว่าวัตถุทุกชิ้นที่สร้างขึ้นต้องเป็นโรงงาน NInject เท่านั้น ตัวอย่างเช่นถ้าในหน้าต่างใด ๆ ในรูปแบบButton_Clickเหตุการณ์ฉันเขียน: TestClass testClass = new TestClass() และTestClassมีการพึ่งพาพูดพูดITestแล้วมันจะต้องได้รับการแก้ไขโดยอัตโนมัติ ฉันรู้ว่าฉันสามารถใช้: Ikernel kernel = new StandardKenel() //AddBinding() TestClass testClass = …

27 .net  design-patterns  unit-testing  dependency-injection 

ฉันมีคำถามง่าย ๆ และฉันก็ไม่แน่ใจด้วยซ้ำว่ามีคำตอบลองทำดู ฉันกำลังเขียนโปรแกรมใน C ++ และใช้การฉีดพึ่งพาเพื่อหลีกเลี่ยงสถานะทั่วโลก มันใช้งานได้ค่อนข้างดีและฉันไม่ได้ทำงานในพฤติกรรมที่ไม่คาดคิด / ไม่ได้กำหนดบ่อยมาก อย่างไรก็ตามฉันตระหนักว่าเมื่อโครงการของฉันเติบโตขึ้นฉันกำลังเขียนโค้ดจำนวนมากซึ่งฉันคิดว่าสำเร็จรูป เลวร้ายยิ่งกว่าความจริงที่ว่ามีรหัสสำเร็จรูปมากกว่ารหัสจริงทำให้บางครั้งก็ยากที่จะเข้าใจ ไม่มีอะไรที่จะเป็นตัวอย่างที่ดีได้ดังนั้นลองทำกัน: ฉันมีคลาสที่ชื่อว่า TimeFactory ซึ่งสร้าง Time object สำหรับรายละเอียดเพิ่มเติม (ไม่แน่ใจว่าเกี่ยวข้องหรือไม่): วัตถุเวลาค่อนข้างซับซ้อนเนื่องจากเวลาสามารถมีรูปแบบที่แตกต่างกันและการแปลงระหว่างวัตถุเหล่านั้นไม่ใช่เชิงเส้นหรือตรงไปตรงมา "เวลา" แต่ละครั้งมีซิงโครไนเซอร์เพื่อจัดการกับการแปลงและเพื่อให้แน่ใจว่าพวกเขามีซิงโครไนซ์เดียวกันเริ่มต้นได้อย่างถูกต้องฉันใช้ TimeFactory TimeFactory มีเพียงหนึ่งอินสแตนซ์และเป็นแอพพลิเคชั่นที่กว้างดังนั้นมันจึงมีคุณสมบัติสำหรับซิงเกิลตัน แต่เนื่องจากมันไม่แน่นอนฉันไม่ต้องการทำให้มันเป็นซิงเกิลตัน ในแอพของฉันมีคลาสจำนวนมากที่ต้องสร้างวัตถุเวลา บางครั้งคลาสเหล่านั้นซ้อนกันอย่างล้ำลึก สมมติว่าฉันมีคลาส A ซึ่งมีอินสแตนซ์ของคลาส B และอื่น ๆ จนถึงคลาส D คลาส D จำเป็นต้องสร้างวัตถุเวลา ในการปฏิบัติที่ไร้เดียงสาของฉันฉันส่ง TimeFactory ไปยังตัวสร้างของคลาส A ซึ่งส่งผ่านไปยังตัวสร้างของคลาส B และต่อไปจนถึงคลาส D ตอนนี้ลองนึกภาพว่าฉันมีคลาสสองชั้นเช่น TimeFactory …

25 c++  dependency-injection 

ฉันเพิ่งทำงานกับโครงการ Python ที่เราทำการฉีดอย่างหนัก (เพราะเราต้องเพื่อให้แอปทดสอบได้) แต่เราไม่ได้ใช้เฟรมเวิร์กใด ๆ บางครั้งมันก็น่าเบื่อนิดหน่อยเมื่อเทียบกับการพึ่งพาทั้งหมดด้วยตนเอง แต่โดยรวมแล้วก็ใช้งานได้ดี เมื่อวัตถุต้องถูกสร้างในหลาย ๆ ที่เราก็มีฟังก์ชั่น (บางครั้งเป็นวิธีการเรียนของวัตถุนั้น) เพื่อสร้างอินสแตนซ์การผลิต ฟังก์ชั่นนี้ถูกเรียกเมื่อใดก็ตามที่เราต้องการวัตถุนั้น ในการทดสอบเราทำสิ่งเดียวกัน: หากหลายครั้งเราจำเป็นต้องสร้าง 'รุ่นทดสอบ' ของวัตถุ (เช่นอินสแตนซ์จริงที่ถูกสำรองข้อมูลโดยวัตถุจำลอง) เรามีฟังก์ชั่นเพื่อสร้าง 'รุ่นทดสอบ' นี้ ของคลาสที่จะใช้ในการทดสอบ ดังที่ฉันพูดโดยทั่วไปแล้วสิ่งนี้ใช้ได้ดี ตอนนี้ฉันกำลังเข้าสู่โครงการ Java ใหม่และเรากำลังตัดสินใจว่าจะใช้เฟรมเวิร์ก DI หรือทำ DI ด้วยตนเอง (เช่นในโครงการก่อนหน้านี้) โปรดอธิบายว่าการทำงานกับกรอบงาน DI จะแตกต่างกันอย่างไรและในลักษณะใดมันจะดีกว่าหรือแย่กว่าการฉีด 'vanilla' แบบพึ่งพา แก้ไข: ฉันต้องการเพิ่มคำถาม: คุณเคยเห็นโครงการ 'ระดับมืออาชีพ' ที่ทำ DI ด้วยตนเองโดยไม่มีกรอบหรือไม่

24 java  dependency-injection  frameworks 

ฉันทำงานเกี่ยวกับการออกแบบ แต่กดปุ่มสิ่งกีดขวางบนถนนต่อไป ฉันมีคลาสเฉพาะ (ModelDef) ที่เป็นหลักเจ้าของต้นไม้โหนดซับซ้อนที่สร้างขึ้นโดยการแยก XML schema (คิด DOM) ฉันต้องการปฏิบัติตามหลักการออกแบบที่ดี (SOLID) และตรวจสอบให้แน่ใจว่าระบบผลลัพธ์นั้นสามารถทดสอบได้ง่าย ฉันมีความตั้งใจที่จะใช้ DI เพื่อส่งผ่านการพึ่งพาในตัวสร้างของ ModelDef (เพื่อให้สามารถสลับสิ่งเหล่านี้ได้อย่างง่ายดายถ้าจำเป็นระหว่างการทดสอบ) แม้ว่าสิ่งที่ฉันกำลังดิ้นรนคือการสร้างทรีโหนด ต้นไม้นี้จะถูกสร้างขึ้นด้วยวัตถุ "ค่า" อย่างง่ายซึ่งไม่จำเป็นต้องทำการทดสอบอย่างอิสระ (อย่างไรก็ตามฉันยังอาจส่ง Abstract Factory ไปยัง ModelDef เพื่อช่วยในการสร้างวัตถุเหล่านี้) แต่ฉันอ่านต่อไปว่าคอนสตรัคเตอร์ไม่ควรทำงานจริงใด ๆ (เช่นFlaw: Constructor ทำงานจริง ) นี่เป็นเหตุผลที่เหมาะสมสำหรับฉันหาก "งานจริง" หมายถึงการสร้างวัตถุที่ต้องอาศัยน้ำหนักมากซึ่งในภายหลังอาจต้องการเริ่มต้นการทดสอบ (สิ่งเหล่านั้นควรถูกส่งผ่านทาง DI) แต่สิ่งที่เกี่ยวกับวัตถุค่าน้ำหนักเบาเช่นต้นไม้โหนดนี้ ต้องสร้างต้นไม้ที่ไหนสักแห่งใช่มั้ย ทำไมไม่สร้างผ่าน ModelDef (ใช้, พูด, buildNodeTree () วิธี)? ฉันไม่ต้องการสร้างทรีโหนดด้านนอกของ ModelDef แล้วผ่านมันใน …

23 java  design  design-patterns  dependency-injection  constructors 

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

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

ฉันต้องการเริ่มต้น Domain-Driven-Design แต่มีปัญหาหลายอย่างที่ฉันต้องการแก้ไขก่อนเริ่มต้น :) ลองนึกภาพฉันมีกลุ่มและผู้ใช้และเมื่อผู้ใช้ต้องการเข้าร่วมกลุ่มฉันกำลังเรียกgroupsService.AddUserToGroup(group, user)วิธี ใน DDD ฉันควรทำgroup.JoinUser(user)ซึ่งดูดีทีเดียว ปัญหาจะปรากฏขึ้นหากฉันมีกฎการตรวจสอบความถูกต้องบางประการสำหรับการเพิ่มผู้ใช้หรืองานภายนอกบางอย่างจำเป็นต้องเริ่มต้นเมื่อมีการเพิ่มผู้ใช้ในกลุ่ม การมีงานเหล่านี้จะนำไปสู่เอนทิตีที่มีการอ้างอิงภายนอก ตัวอย่างอาจเป็น - ข้อ จำกัด ที่ผู้ใช้สามารถเข้าร่วมได้สูงสุด 3 กลุ่มเท่านั้น วิธีนี้จะต้องใช้การเรียก DB จากภายในกลุ่มวิธีใช้ JoinUser เพื่อตรวจสอบความถูกต้องนี้ แต่ความจริงที่ว่า Entity นั้นขึ้นอยู่กับบริการ / คลาสภายนอกบางอย่างนั้นดูไม่ดีนัก วิธีที่เหมาะสมในการจัดการกับสิ่งนี้ใน DDD คืออะไร?

22 c#  dependency-injection  domain-driven-design 

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

21 design-patterns  unit-testing  functional-programming  dependency-injection 

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

21 .net  dependency-injection  ioc-containers