ข้อดีข้อเสียของการใช้ Enterprise Library Unity เทียบกับคอนเทนเนอร์ IoC อื่น ๆ (Windsor, Spring.Net, Autofac .. ) คืออะไร?
ข้อดีข้อเสียของการใช้ Enterprise Library Unity เทียบกับคอนเทนเนอร์ IoC อื่น ๆ (Windsor, Spring.Net, Autofac .. ) คืออะไร?
คำตอบ:
ฉันกำลังเตรียมงานนำเสนอสำหรับกลุ่มผู้ใช้ ดังนั้นฉันจึงเดินผ่านพวกมัน ได้แก่ : AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity และ Windsor
ฉันต้องการอวดเคส 90% (การฉีดตัวสร้างซึ่งส่วนใหญ่เป็นสิ่งที่ผู้คนใช้ IOC เป็นหลัก) คุณสามารถตรวจสอบวิธีแก้ปัญหาได้ที่นี่ (VS2008)
ด้วยเหตุนี้จึงมีความแตกต่างที่สำคัญบางประการ:
แต่ละตัวมีคุณสมบัติอื่น ๆ เช่นกัน (บางตัวมี AOP และ gizmos ที่ดีกว่า แต่โดยทั่วไปสิ่งที่ฉันต้องการให้ IOC ทำคือสร้างและดึงข้อมูลวัตถุให้ฉัน)
หมายเหตุ: ความแตกต่างระหว่างการดึงอ็อบเจ็กต์ไลบรารีที่แตกต่างกันสามารถลบล้างได้โดยใช้ CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator
นั่นทำให้เราเริ่มต้นได้ซึ่งทำได้สองวิธี: ผ่านโค้ดหรือผ่านการกำหนดค่า XML (app.config / web.config / custom.config) บางคนสนับสนุนทั้งสองอย่างบางคนสนับสนุนเพียงคนเดียว ฉันควรทราบ: คุณลักษณะบางอย่างใช้เพื่อช่วย IoC พร้อม
ดังนั้นนี่คือการประเมินความแตกต่างของฉัน:
การเริ่มต้นรหัสเท่านั้น (พร้อมแอตทริบิวต์) ฉันหวังว่าคุณจะชอบ lambdas รหัสเริ่มต้นมีลักษณะดังนี้:
IKernel kernel = new StandardKernel(
new InlineModule(
x => x.Bind<ICustomerRepository>().To<CustomerRepository>(),
x => x.Bind<ICustomerService>().To<CustomerService>(),
x => x.Bind<Form1>().ToSelf()
));
รหัสเริ่มต้นหรือ XML หรือแอตทริบิวต์ v2.5 ยังเป็นแลมบ์ดา 'มาก สรุปแล้วนี่คือหนึ่งในรายการโปรดของฉัน แนวคิดที่น่าสนใจเกี่ยวกับการที่ StructureMap ใช้ Attributes
ObjectFactory.Initialize(x =>
{
x.UseDefaultStructureMapConfigFile = false;
x.ForRequestedType<ICustomerRepository>()
.TheDefaultIsConcreteType<CustomerRepository>()
.CacheBy(InstanceScope.Singleton);
x.ForRequestedType<ICustomerService>()
.TheDefaultIsConcreteType<CustomerService>()
.CacheBy(InstanceScope.Singleton);
x.ForConcreteType<Form1>();
});
รหัสเริ่มต้นและ XML ห้องสมุดที่ดี แต่การกำหนดค่า XML เป็นความเจ็บปวดที่ก้น ห้องสมุดที่ยอดเยี่ยมสำหรับ Microsoft หรือร้านค้าบนทางหลวง การเริ่มต้นรหัสเป็นเรื่องง่าย:
container.RegisterType<ICustomerRepository, CustomerRepository>()
.RegisterType<ICustomerService, CustomerService>();
XML ใกล้เคียงที่สุดเท่าที่ฉันสามารถบอกได้ แต่สำหรับฟังก์ชั่น Spring.Net ทำทุกอย่างภายใต้แสงแดดที่ IoC สามารถทำได้ แต่เนื่องจากวิธีเดียวที่จะทำให้เป็นหน่วยได้คือผ่าน XML จึงมักหลีกเลี่ยงโดยร้านค้า. net แม้ว่าร้านค้า. net / Java จำนวนมากจะใช้ Spring.Net เนื่องจากความคล้ายคลึงกันระหว่าง Spring.Net เวอร์ชัน. net และโครงการ Java Spring
หมายเหตุ : การกำหนดค่าในรหัสนี้เป็นไปได้ด้วยการแนะนำของSpring.NET CodeConfig
XML และรหัส เช่นเดียวกับ Spring.Net วินด์เซอร์จะทำทุกอย่างที่คุณต้องการให้ทำ วินด์เซอร์น่าจะเป็นตู้คอนเทนเนอร์ IoC ที่ได้รับความนิยมมากที่สุดแห่งหนึ่ง
IWindsorContainer container = new WindsorContainer();
container.AddComponentWithLifestyle<ICustomerRepository, CustomerRepository>("CustomerRepository", LifestyleType.Singleton);
container.AddComponentWithLifestyle<ICustomerService, CustomerService>("CustomerService",LifestyleType.Singleton);
container.AddComponent<Form1>("Form1");
สามารถผสมทั้ง XML และรหัส (กับ v1.2) ห้องสมุด IoC ที่เรียบง่ายดี ดูเหมือนจะทำพื้นฐานด้วยไม่เอะอะมาก รองรับคอนเทนเนอร์ที่ซ้อนกันด้วยการกำหนดขอบเขตของส่วนประกอบในพื้นที่และการจัดการอายุการใช้งานที่กำหนดไว้อย่างดี
นี่คือวิธีเริ่มต้น:
var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
.As<ICustomerRepository>()
.ContainerScoped();
builder.Register<CustomerService>()
.As<ICustomerService>()
.ContainerScoped();
builder.Register<Form1>();
ถ้าต้องเลือกวันนี้: ผมคงไปกับ StructureMap มีการสนับสนุนที่ดีที่สุดสำหรับคุณสมบัติภาษา C # 3.0 และความยืดหยุ่นสูงสุดในการเริ่มต้น
เท่าที่ฉันเห็นพวกเขาค่อนข้างเหมือนกันยกเว้นรายละเอียดการใช้งานเล็กน้อยที่นี่และที่นั่น ข้อได้เปรียบที่ใหญ่ที่สุดที่ Unity มีเหนือคู่แข่งคือ Microsoft จัดหาให้มี บริษัท มากมายที่กลัว OSS
ข้อเสียอย่างหนึ่งคือมันค่อนข้างใหม่ดังนั้นจึงอาจมีข้อบกพร่องที่ผู้เล่นรุ่นเก่าได้แยกแยะออกไปแล้ว
กระทู้เก่า แต่เนื่องจากนี่เป็นสิ่งแรกที่ Google แสดงให้ฉันเห็นเมื่อฉันพิมพ์ใน unity vs spring.net ...
Spring ทำ CodeConfig ทันทีหากคุณไม่ชอบการกำหนดค่า XML
http://www.springframework.net/codeconfig/doc-latest/reference/html/
นอกจากนี้ Spring ยังเป็นมากกว่าคอนเทนเนอร์ DI หากคุณดูที่ส่วน 'โมดูล' ในเอกสารคอนเทนเนอร์ DI เป็นรากฐานของสิ่งต่างๆมากมายที่มันทำ
แก้ไขฉันถ้าฉันเข้าใจผิด แต่ฉันคิดว่า Autofac เองรองรับการกำหนดค่า XML ตามที่ระบุไว้ในลิงค์นี้: Autofac XML Configuration
Spring มีคุณสมบัติอย่างหนึ่งที่สามารถฉีดพารามิเตอร์ให้กับตัวสร้างหรือคุณสมบัติตามชื่อพารามิเตอร์หรือตำแหน่ง สิ่งนี้มีประโยชน์มากหากพารามิเตอร์หรือคุณสมบัติเป็นชนิดธรรมดา (เช่นจำนวนเต็มบูลีน) ดูตัวอย่างที่นี่ ฉันไม่คิดว่าสิ่งนี้ทำให้ Spring ไม่สามารถกำหนดค่าในโค้ดได้จริงๆ
วินด์เซอร์สามารถทำได้เช่นกันและสามารถทำได้ในรหัสไม่ใช่ config (แก้ไขฉันถ้าฉันผิดฉันแค่อธิบายสิ่งที่ฉันได้ยินที่นี่)
ฉันต้องการทราบว่า Unity สามารถทำได้หรือไม่
สิ่งหนึ่งที่ควรทราบ: Ninject เป็นคอนเทนเนอร์ IoC เดียวที่รองรับการแทรกการพึ่งพาตามบริบท (ตามเว็บไซต์) อย่างไรก็ตามเนื่องจากฉันไม่มีประสบการณ์กับคอนเทนเนอร์ IoC อื่นฉันจึงไม่สามารถบอกได้ว่าสิ่งนั้นมีอยู่จริงหรือไม่
เพื่อเพิ่ม 2 เซ็นต์ของฉันฉันได้ลองทั้ง StructureMap และ Unity ฉันพบว่า StructureMap มีเอกสารไม่ดี / เข้าใจผิดมีความเจ็บปวดที่ก้นในการกำหนดค่าและใช้งานไม่สะดวก ในทำนองเดียวกันดูเหมือนว่าจะไม่สนับสนุนสถานการณ์เช่นอาร์กิวเมนต์ตัวสร้างแทนที่ในเวลาแก้ปัญหาซึ่งเป็นจุดใช้งานที่สำคัญสำหรับฉัน ดังนั้นฉันจึงทิ้งมันและไปด้วย Unity และให้มันทำในสิ่งที่ฉันต้องการในเวลาประมาณ 20 นาที
ฉันเองใช้ Unity แต่เพียงเพราะมาจาก Microsoft ฉันเสียใจที่ตัดสินใจด้วยเหตุผลเดียว: สิ่งที่ยิ่งใหญ่ที่สุดที่มีต่อมันมี "ข้อบกพร่อง" ใหญ่อย่างหนึ่งที่ทำให้เกิดข้อยกเว้นอยู่ตลอดเวลา คุณสามารถเพิกเฉยต่อข้อยกเว้นในขณะที่แก้ไขข้อบกพร่อง อย่างไรก็ตามจะทำให้แอปพลิเคชันของคุณช้าลงอย่างมากหากคุณใช้งานข้ามมันเนื่องจากการทิ้งข้อยกเว้นเป็นการดำเนินการที่มีราคาแพง ตัวอย่างเช่นขณะนี้ฉันกำลัง "แก้ไข" ข้อยกเว้นนี้ในจุดเดียวในโค้ดของฉันซึ่งข้อยกเว้นของ Unity จะเพิ่มเวลาในการแสดงผลของหน้าอีก4 วินาที สำหรับรายละเอียดเพิ่มเติมและวิธีแก้ไขปัญหาโปรดดู:
Unity สามารถทำให้ไม่โยน SynchronizationLockException ตลอดเวลาได้หรือไม่?