Ninject vs Unity สำหรับ DI [ปิด]


104

เราใช้ ASP.net MVC

Ninject หรือ Unity ของเฟรมเวิร์ก DI ตัวใดที่ดีที่สุดและเพราะเหตุใด


94
NInject ดีกว่าเพราะคุณสามารถซื้อแม่เหล็กเย็น ๆ จากเว็บไซต์ของพวกเขาได้
Ivan G.

5
เวอร์ชันอัปเดตของคำถามนี้ (คล้ายกันมาก) ที่บางคนอาจพบว่ามีประโยชน์: stackoverflow.com/questions/4581791/…
Jason Down

คำตอบ:


46

ครั้งสุดท้ายที่ฉันดูทั้งสองอย่างฉันพบว่า Ninject ดีขึ้นเล็กน้อย แต่ทั้งสองมีข้อเสีย

Ninject มีโครงร่างการกำหนดค่าที่คล่องแคล่วดีกว่า Unity ดูเหมือนจะอาศัยการกำหนดค่า XML เป็นส่วนใหญ่ ข้อเสียเปรียบหลักของ Ninject คือคุณต้องอ้างอิง Ninject.Core ทุกที่ในโค้ดของคุณเพื่อเพิ่มแอตทริบิวต์ [Inject]

ถ้าฉันอาจถามว่าทำไมคุณถึง จำกัด ตัวเลือกของคุณไว้ที่สองคนนี้ ฉันคิดว่า Castle.Windsor, Autofac และ StructureMap เป็นอย่างน้อยก็ดีหรือดีกว่า


47
คุณจะต้องใช้แอตทริบิวต์ Inject เท่านั้นหากมีตัวสร้างมากกว่าหนึ่งตัวและคุณต้องบอก Ninject ว่าจะใช้ตัวสร้างใด โดยค่าเริ่มต้นจะใช้ตัวสร้างที่มีพารามิเตอร์จำนวนมากที่สุด
Jeffrey Cameron

11
ในระหว่างนี้ยังมีส่วนขยาย Ninject.Web.Mvc อย่างเป็นทางการ คุณเปลี่ยน MvcApplication ของคุณให้ได้มาจาก NinjectHttpApplication หมุนเคอร์เนลในนั้นแล้วเรียก RegisterAllControllersIn (Assembly.GetExecutingAssembly ()) เพื่อให้มันดูแลคอนโทรลเลอร์ทั้งหมดในแอสเซมบลีที่กำหนด มายากล.
Michael Stum

18
ตอนนี้คำตอบนี้ไม่เกี่ยวข้องกับการตอบกลับไปยัง Ninject 2 ในขณะที่การร้องเรียนนั้นถูกต้องตามกฎหมายสำหรับ Ninject 1 Ninject 2 อนุญาตให้ทำงานได้โดยไม่ทิ้งขยะในชั้นเรียนที่มีคุณลักษณะ Ninject2 จะทำงานอย่างโปร่งใสโดยไม่จำเป็นต้องปรับเปลี่ยนคลาสของคุณ
chillitom

3
เช่นเดียวกับความสามัคคีเนื่องจากดูเหมือนว่าจะสามารถกำหนดค่าได้อย่างสมบูรณ์ผ่านรหัส ณ จุดนี้ (v3.0.1304.1)
Eric

46

ฉันรู้ว่านี่เป็นคำถามเก่า แต่นี่คือความคิดของฉัน:

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

ฉันคิดถึง ObjectFactory ของ StructureMap แต่มีวิธีแก้ปัญหาง่ายๆในการเพิ่มสิ่งนั้นใน Ninject

ดังที่ Jeffery ชี้ให้เห็นว่าคุณไม่จำเป็นต้องใช้แอตทริบิวต์ [Inject] เมื่อคุณมีตัวสร้างเพียงตัวเดียว

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


10

Ninject ตรวจพบการอ้างอิงแบบวงกลมหากคุณใช้ Injection Constructors ซึ่งตรงข้ามกับ Unity ที่ไม่ว่าจะใช้เทคนิคการฉีดแบบใดเพียงแค่พ่น StackOverflowException ซึ่งยากมากที่จะดีบัก


9

ฉันเห็นด้วยกับ Mendelt ไม่มีกรอบ DI "ที่ดีที่สุด" มันขึ้นอยู่กับสถานการณ์และทุกอย่างมีข้อดีข้อเสีย คิดว่า David Hayden กล่าวใน DotNet Rocks ว่า Unity เป็นตัวเลือกที่ต้องการหากคุณใช้ EntLib ที่เหลือและคุ้นเคยกับสิ่งนั้น ฉันใช้ Unity เป็นการส่วนตัวเพราะลูกค้าของฉันชอบความจริงที่ว่าMicrosoft Enterprise Library (Unity) บน DLLs ถ้าคุณได้รับสิ่งที่ฉันพูด

ฉันใช้ทั้งการกำหนดค่า xml สำหรับการตั้งค่าอินเทอร์เฟซและการใช้งานคอนกรีต แต่จากนั้นฉันใช้แอตทริบิวต์ในโค้ดเมื่อทำการฉีดเช่น:

<type type="ILogger" mapTo="EntLibLogger">
   <lifetime type="singleton"/>
</type>

และในรหัส:

[InjectionConstructor]
public Repository([Dependency] ILogger logger)

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


โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.