กรอบงาน C # DI / IoC หลักเปรียบเทียบได้อย่างไร [ปิด]


308

เมื่อมีความเสี่ยงในการก้าวเข้าสู่ดินแดนสงครามศักดิ์สิทธิ์จุดแข็งและจุดอ่อนของกรอบ DI / IoC ที่ได้รับความนิยมเหล่านี้คืออะไรและใครจะถือว่าดีที่สุดได้อย่างง่ายดาย .. :

  • Ninject
  • เอกภาพ
  • Castle.Windsor
  • Autofac
  • StructureMap

มี DI / IoC Frameworks อื่น ๆ สำหรับ C # ที่ฉันไม่ได้ระบุไว้ที่นี่หรือไม่?

ในบริบทของกรณีการใช้งานของฉันฉันกำลังสร้างแอป WPF ของลูกค้าและโครงสร้างพื้นฐานบริการ WCF / SQL ใช้งานง่าย (โดยเฉพาะอย่างยิ่งในแง่ของไวยากรณ์ที่ชัดเจนและรัดกุม) เอกสารที่สอดคล้องกันการสนับสนุนชุมชนที่ดีและประสิทธิภาพเป็นปัจจัยสำคัญทั้งหมด ในการเลือกของฉัน

ปรับปรุง:

ทรัพยากรและคำถามซ้ำ ๆ ที่อ้างถึงดูเหมือนจะล้าสมัยใครที่มีความรู้ในกรอบเหล่านี้จะออกมาข้างนอกและให้ข้อมูลเชิงลึกที่แท้จริงบ้างไหม?

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

ฉันค่อนข้างเต็มใจที่จะทำการสอบสวนของตัวเองหากยังไม่เคยทำมาก่อน แต่ฉันคิดว่านี่เป็นสิ่งที่คนอย่างน้อยสองสามคนได้ทำไปแล้ว

อัปเดตที่สอง:

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


1
คำถามเดียวกับ [Ninject vs Unity for DI] ( stackoverflow.com/questions/1054801/ninject-vs-unity-for-di ) แต่อาจต้องใช้เวลาในการติดตาม
Matthew Flaschen

2
สำเนาซ้ำได้ของ [เปรียบเทียบ Castle Windsor, Unity และ StructureMap] ( stackoverflow.com/questions/2216684/ … )
Mauricio Scheffer

@slomojo: เป็นไปได้ที่ซ้ำกัน stackoverflow.com/questions/4509458/ioc-comparisions-closed นอกจากนี้ยังมีลิงค์ที่แสดงความนิยมของ IoC ในคำตอบ ดูที่มัน
dhinesh

@chibacity - ฉันเคยใช้กับ ... 4 โปรเจ็กต์, สองอันแรกนั้นพื้นฐานจริงๆ, ไม่มีปัญหา, สองอันที่สอง, ความสามัคคีทำให้เรามีปัญหามากมายเมื่อพูดถึงการฉีดคอนสตรัคเตอร์, การบำรุงรักษา, การอ่านง่าย เราลงเอยด้วยการฉีก Unity จากทั้งสองและแทนที่ด้วย StructureMap การสร้างคอนสตรัคชันนั้นง่ายมากการกำหนดค่านั้นสะอาดและบำรุงรักษาได้ ในเวลาส่วนตัวของฉันฉันได้เล่นกับ AutoFac แต่ฉันพบว่ามันเล่นแร่แปรธาตุใช้เอกสารบางอย่างเพื่อทำความเข้าใจให้ดีขึ้น ที่เหลือฉันสามารถแสดงความคิดเห็นในสิ่งที่ฉันได้อ่าน
Phill

ปัญหาหนึ่งที่เรามีกับ SSRS มันล้มเหลวอย่างเงียบ ๆ และก้าวผ่านรหัสที่เราไม่สามารถเข้าใจได้ว่าทำไมมันถึงล้มเหลวข้อยกเว้นนั้นคลุมเครือ เราใช้เวลาหนึ่งสัปดาห์ในการเขียนวิธีการทำงานเพื่อให้มันทำงานได้ ในที่สุดเมื่อเราย้ายไปที่ StructureMap เราได้ลองอีกครั้งและภายในไม่กี่นาทีโดยใช้ 'ObjectFactory.WhatDoIHave ()' เราได้เรียนรู้ว่า IoC กำลังถูกสร้างขึ้นก่อนที่แอสเซมบลีจะถูกโหลดลงใน AppDomain ดังนั้นอินเทอร์เฟซ ประเภท
Phill

คำตอบ:


225

ในขณะที่คำตอบที่ครอบคลุมสำหรับคำถามนี้ใช้เวลาหลายร้อยหน้าของหนังสือของฉันนี่คือแผนภูมิเปรียบเทียบแบบย่อที่ฉันยังคงทำงานอยู่:

ตารางอธิบายความแตกต่างระหว่าง DIC หลายตัว


40
ฉันอ่าน MEAP ในหนังสือของคุณแล้วและสงสัยว่าทำไมคุณถึงออกจาก Ninject ไป?
Martin Owen

2
คำตอบบางส่วนสามารถพบได้ที่นี่: manning-sandbox.com/thread.jspa?threadID=38943
Mark Seemann

25
@ Mark ขอบคุณสำหรับการนี้หวังว่าคำตอบของคุณอาจรวมถึง Ninject (สำคัญไม่เพียงเพราะของ hype ใหม่รอบ แต่ยังเนื่องจากมันใช้คุณสมบัติภาษาใหม่.)
ocodo

3
Ninject ในขณะที่คล้ายกับ AutoFac นั้นมีหลายวิธีมันถูกใช้โดย NUGET Team และคอนเทนเนอร์ IOC ที่ได้รับความนิยมสูงสุดดาวน์โหลดลงมือ ฉันผิดหวังที่มันไม่ได้อยู่ในการฉีดพึ่งพามาร์คในหนังสือ. NET หากมีรุ่นที่ 2 ในลักษณะที่อุตสาหกรรมหวังว่ามันจะทำให้มันเป็นหนังสือ ฉันทำงานเป็น Unity, MEF (ไม่ใช่ DI จริง), Ninject หรือ StructurMap ฉันยังไม่ได้ลงนามในสัญญาหรือกิ๊กระยะไกลที่ใช้ spring.net หรือ autofac เป็นต้น ...
Tom Stickel

2
ความสามัคคี 3.5 แล้วสนับสนุนการลงทะเบียนตามการประชุม: nuget.org/packages/Unity/3.5.1404 ลบข้อเสียหนึ่ง ;-)
Vladimir Dorokhov

116

ฉันเจอการเปรียบเทียบประสิทธิภาพอื่น(อัปเดตล่าสุด 10 เมษายน 2557) มันเปรียบเทียบดังต่อไปนี้:

นี่คือการสรุปอย่างย่อจากโพสต์:

ข้อสรุป

Ninject เป็นภาชนะที่ช้าที่สุดอย่างแน่นอน

MEF, LinFu และ Spring.NET นั้นเร็วกว่า Ninject แต่ก็ค่อนข้างช้า AutoFac, Catel และ Windsor มาถัดไปตามด้วย StructureMap, Unity และ LightCore ข้อเสียของ Spring.NET คือสามารถกำหนดค่าได้ด้วย XML เท่านั้น

SimpleInjector, Hiro, Funq, Munq และ Dynamo ให้ประสิทธิภาพที่ดีที่สุดและรวดเร็วมาก ลองดูสิ!

โดยเฉพาะ Simple Injector น่าจะเป็นตัวเลือกที่ดี มันเร็วมากมีเอกสารที่ดีและยังรองรับสถานการณ์ขั้นสูงเช่นการสกัดกั้นและมัณฑนากรทั่วไป

คุณยังสามารถลองใช้Library Selector Commonและหวังว่าจะลองใช้ตัวเลือกหลายตัวและดูว่าอะไรดีที่สุดสำหรับคุณ

ข้อมูลบางอย่างเกี่ยวกับ Library Selector Common จากเว็บไซต์:

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

ปรับปรุง

13.09.2011: เพิ่ม FunqและMunqไปยังรายการของผู้แข่งขัน แผนภูมิได้รับการปรับปรุงด้วยเช่นกันและ Spring.NET ถูกลบเนื่องจากประสิทธิภาพที่ไม่ดี

04.11.2011: "เพิ่มSimple Injectorประสิทธิภาพที่ดีที่สุดของผู้เข้าแข่งขันทุกคน"


(จากการติดตามลิงก์เปรียบเทียบ) อัปเดตเมื่อเร็ว ๆ นี้น่าสนใจเพื่อดูความแตกต่างของความเร็ว (บวกกับเมทริกซ์คุณลักษณะพื้นฐาน) ขอบคุณ
lko

การเปรียบเทียบนั้นไม่น่าเชื่อถือเพราะเท่าที่ฉันทราบ Ninject มีส่วนขยายสำหรับทั้งการสกัดกั้นและการกำหนดค่า XML ในขณะที่การเปรียบเทียบระบุว่าไม่
Daniel

15
นี่เป็นการเปรียบเทียบเชิงปริมาณอย่างมาก คุณลักษณะที่ไม่เกี่ยวกับประสิทธิภาพเช่นขนาดไฟล์หรือจำนวนการอ้างอิงที่ต้องการคืออะไร นอกจากนี้การวัดแบบอัตนัยเช่นคุณภาพเอกสารหรือการใช้งานจะเป็นประโยชน์ ประเด็นของฉันคือมีปัจจัยที่ต้องพิจารณานอกเหนือจากความเร็ว
FistOfFury

1
เช่นเดียวกับ Jeremy Miller ผู้เขียน StructureMap ได้กล่าวในอดีต ... การถอดความ - แน่นอนว่ามี IOC เร็วกว่าคอนเทนเนอร์ แต่ขาดคุณสมบัติครบถ้วน
Tom Stickel

ตรวจสอบสิ่งนี้: iocservicestack.net
Rajesh Jinaga

49

เพียงแค่อ่านบล็อกการเปรียบเทียบคอนเทนเนอร์. net DIที่ยอดเยี่ยมนี้โดย Philip Mat

เขาทำการทดสอบเปรียบเทียบประสิทธิภาพอย่างละเอียดกับ;

เขาแนะนำให้Autofacเพราะมันเล็กเร็วและใช้งานง่าย ... ฉันเห็นด้วย ดูเหมือนว่าUnity and Ninjectนั้นช้าที่สุดในการทดสอบของเขา


5
มีการอัปเดตไปยังโพสต์. Net DI Container Redux Redux : ในบรรทัดล่างมีวิธีการที่ไม่ถูกต้องสำหรับ Unity ตั้งแต่แรก ด้วยการวัดใหม่ Unity ดูดีขึ้นมาก
Volker von Einem

33

ข้อจำกัดความรับผิดชอบ:ณ ต้นปี 2558 มีการเปรียบเทียบคุณสมบัติ IoC Container จากJimmy Bogard ที่ยอดเยี่ยมนี่เป็นบทสรุป:

เปรียบเทียบภาชนะบรรจุ:

  • Autofac
  • Ninject
  • หัวฉีดง่าย
  • StructureMap
  • เอกภาพ
  • วินด์เซอร์

สถานการณ์คือ: ฉันมีส่วนต่อประสาน, IMediator, ซึ่งฉันสามารถส่งคำขอ / ตอบกลับเดียวหรือการแจ้งเตือนไปยังผู้รับหลายคน:

public interface IMediator 
{ 
    TResponse Send<TResponse>(IRequest<TResponse> request);

    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);

    void Publish<TNotification>(TNotification notification)
        where TNotification : INotification;

    Task PublishAsync<TNotification>(TNotification notification)
        where TNotification : IAsyncNotification; 
}

ฉันสร้างชุดคำขอ / ตอบกลับ / การแจ้งเตือนพื้นฐาน:

public class Ping : IRequest<Pong>
{
    public string Message { get; set; }
}
public class Pong
{
    public string Message { get; set; }
}
public class PingAsync : IAsyncRequest<Pong>
{
    public string Message { get; set; }
}
public class Pinged : INotification { }
public class PingedAsync : IAsyncNotification { }

ฉันสนใจที่จะดูบางสิ่งเกี่ยวกับการสนับสนุนคอนเทนเนอร์สำหรับข้อมูลทั่วไป:

  • ตั้งค่าสำหรับ generics แบบเปิด (การลงทะเบียน IRequestHandler <,> ได้อย่างง่ายดาย)
  • การตั้งค่าสำหรับการลงทะเบียนหลายครั้งของ generics แบบเปิด (INotificationHandlers สองคนขึ้นไป)

การตั้งค่าสำหรับความแปรปรวนทั่วไป (การลงทะเบียนตัวจัดการสำหรับการอ้างอิงพื้นฐาน / การสร้างท่อส่งคำขอ) ตัวจัดการของฉันค่อนข้างตรงไปตรงมาพวกเขาเพียงแค่ส่งออกไปยังคอนโซล:

public class PingHandler : IRequestHandler<Ping, Pong> { /* Impl */ }
public class PingAsyncHandler : IAsyncRequestHandler<PingAsync, Pong> { /* Impl */ }

public class PingedHandler : INotificationHandler<Pinged> { /* Impl */ }
public class PingedAlsoHandler : INotificationHandler<Pinged> { /* Impl */ }
public class GenericHandler : INotificationHandler<INotification> { /* Impl */ }

public class PingedAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }
public class PingedAlsoAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }

Autofac

var builder = new ContainerBuilder();
builder.RegisterSource(new ContravariantRegistrationSource());
builder.RegisterAssemblyTypes(typeof (IMediator).Assembly).AsImplementedInterfaces();
builder.RegisterAssemblyTypes(typeof (Ping).Assembly).AsImplementedInterfaces();
  • ยาชื่อสามัญแบบเปิด: ใช่โดยปริยาย
  • มี generics แบบเปิดหลายตัว: ใช่โดยปริยาย
  • ความแตกต่างทั่วไป: ใช่อย่างชัดเจน

Ninject

var kernel = new StandardKernel();
kernel.Components.Add<IBindingResolver, ContravariantBindingResolver>();
kernel.Bind(scan => scan.FromAssemblyContaining<IMediator>()
    .SelectAllClasses()
    .BindDefaultInterface());
kernel.Bind(scan => scan.FromAssemblyContaining<Ping>()
    .SelectAllClasses()
    .BindAllInterfaces());
kernel.Bind<TextWriter>().ToConstant(Console.Out);
  • ยาชื่อสามัญแบบเปิด: ใช่โดยปริยาย
  • มี generics แบบเปิดหลายตัว: ใช่โดยปริยาย
  • ความแตกต่างทั่วไป: ใช่ด้วยส่วนขยายที่ผู้ใช้สร้างขึ้น

หัวฉีดง่าย

var container = new Container();
var assemblies = GetAssemblies().ToArray();
container.Register<IMediator, Mediator>();
container.Register(typeof(IRequestHandler<,>), assemblies);
container.Register(typeof(IAsyncRequestHandler<,>), assemblies);
container.RegisterCollection(typeof(INotificationHandler<>), assemblies);
container.RegisterCollection(typeof(IAsyncNotificationHandler<>), assemblies);
  • ข้อมูลทั่วไปแบบเปิด: ใช่อย่างชัดเจน
  • หลาย generics เปิด: ใช่อย่างชัดเจน
  • ความแตกต่างทั่วไป: ใช่โดยนัย (พร้อมอัปเดต 3.0)

StructureMap

var container = new Container(cfg =>
{
    cfg.Scan(scanner =>
    {
        scanner.AssemblyContainingType<Ping>();
        scanner.AssemblyContainingType<IMediator>();
        scanner.WithDefaultConventions();
        scanner.AddAllTypesOf(typeof(IRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(IAsyncRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(INotificationHandler<>));
        scanner.AddAllTypesOf(typeof(IAsyncNotificationHandler<>));
    });
});
  • ข้อมูลทั่วไปแบบเปิด: ใช่อย่างชัดเจน
  • หลาย generics เปิด: ใช่อย่างชัดเจน
  • ความแตกต่างทั่วไป: ใช่โดยปริยาย

เอกภาพ

container.RegisterTypes(AllClasses.FromAssemblies(typeof(Ping).Assembly),
   WithMappings.FromAllInterfaces,
   GetName,
   GetLifetimeManager);

/* later down */

static bool IsNotificationHandler(Type type)
{
    return type.GetInterfaces().Any(x => x.IsGenericType && (x.GetGenericTypeDefinition() == typeof(INotificationHandler<>) || x.GetGenericTypeDefinition() == typeof(IAsyncNotificationHandler<>)));
}

static LifetimeManager GetLifetimeManager(Type type)
{
    return IsNotificationHandler(type) ? new ContainerControlledLifetimeManager() : null;
}

static string GetName(Type type)
{
    return IsNotificationHandler(type) ? string.Format("HandlerFor" + type.Name) : string.Empty;
}
  • ยาชื่อสามัญแบบเปิด: ใช่โดยปริยาย
  • Generics แบบเปิดหลายตัว: ใช่พร้อมส่วนขยายที่ผู้ใช้สร้างขึ้น
  • ความแตกต่างทั่วไป: derp

วินด์เซอร์

var container = new WindsorContainer();
container.Register(Classes.FromAssemblyContaining<IMediator>().Pick().WithServiceAllInterfaces());
container.Register(Classes.FromAssemblyContaining<Ping>().Pick().WithServiceAllInterfaces());
container.Kernel.AddHandlersFilter(new ContravariantFilter());
  • ยาชื่อสามัญแบบเปิด: ใช่โดยปริยาย
  • มี generics แบบเปิดหลายตัว: ใช่โดยปริยาย
  • ความแตกต่างทั่วไป: ใช่ด้วยส่วนขยายที่ผู้ใช้สร้างขึ้น

ยอดเยี่ยม Btw สรุปข้างต้นพลาดวินด์เซอร์ แต่มีอยู่ในบทความต้นฉบับของจิมมี่
Louis

ว้าวไม่มีใครเตือนเรื่องนี้มาก่อน (: ฉันเพิ่มวินด์เซอร์ขอบคุณ @Louis
stratovarius

21

ที่จริงแล้วมีกรอบ IoC มากมาย ดูเหมือนว่าโปรแกรมเมอร์ทุกคนพยายามที่จะเขียนหนึ่งในจุดหนึ่งของอาชีพของพวกเขา อาจจะไม่เผยแพร่ แต่เพื่อเรียนรู้การทำงานภายใน

ฉันชอบ autofac ส่วนตัวเพราะมันค่อนข้างยืดหยุ่นและมีไวยากรณ์ที่เหมาะกับฉัน (แม้ว่าฉันเกลียดจริง ๆ ว่าวิธีการลงทะเบียนทั้งหมดเป็นวิธีส่วนขยาย)

กรอบอื่น ๆ :


สวัสดี @abatishchev! :) ... แนวคิดดั้งเดิมคือการทำให้แน่ใจว่าวิธีการของบุคคลที่สามและวิธีการในตัวอยู่บนพื้นฐานเดียวกัน วิธีการ "register" หลายวิธีต้องจัดส่งแยกต่างหาก (เช่นRegisterControllers()สำหรับ MVC) ดังนั้นฉันจึงคิดว่าการออกแบบรอบ ๆ เคสนั้นคุ้มค่า (สิ่งนี้ได้รับการออกแบบมานานกว่า 5+ ปี)
Nicholas Blumhardt

1
@NicholasBlumhardt: สวัสดี! :) ขออภัยสำหรับการตอบกลับล่าช้าการแจ้งเตือนหายไปจากคนอื่น ๆ เห็นแก่ความมั่นคงเช่นนั้นจริง ๆ แล้วสมเหตุสมผลสำหรับฉัน คุณคิดอย่างไรตอนนี้คุณจะออกแบบมันอย่างไร
abatishchev

@abatishchev ฉันไม่เห็นด้วยกับ jgauffin วิธีการขยายจะไม่ปิดสำหรับการขยายพวกเขาเป็นส่วนขยาย คุณเขียนหลักของเฟรมเวิร์กของคุณที่สามารถทำทุกอย่างที่ควรและด้วยวิธีการขยายที่คุณมีฟังก์ชั่นเพิ่มเติมบางอย่างอาจมีผู้ช่วยเริ่มต้นบางคน แต่คนอื่นมีอิสระที่จะเขียนส่วนขยายของตัวเอง ฉันจะบอกว่าถ้ากรอบงานของคุณยอมรับวิธีการขยายเพื่อขยายมันก็เป็นกรอบที่ดี
t3chb0t

6

ทีนี้หลังจากดูการเปรียบเทียบที่ดีที่สุดที่ฉันเคยพบคือ:

มันเป็นแบบสำรวจความคิดเห็นในเดือนมีนาคม 2010

สิ่งหนึ่งที่น่าสนใจสำหรับฉันคือคนที่เคยใช้ DI / IoC Framework และชอบ / ไม่ชอบมัน StructureMap ดูเหมือนจะออกมาด้านบน

นอกจากนี้จากการสำรวจดูเหมือนว่าCastle.Windsorและโครงสร้างแผนที่ดูเหมือนจะเป็นที่นิยมมากที่สุด

น่าสนใจUnityและSpring.Netดูเหมือนจะเป็นตัวเลือกยอดนิยมที่ไม่ชอบมากที่สุด (ฉันกำลังพิจารณาความสามัคคีจากความเกียจคร้าน (และป้าย / การสนับสนุนของ Microsoft) แต่ฉันจะดูอย่างใกล้ชิดมากขึ้นที่ Castle Windsor และโครงสร้างแผนที่ตอนนี้)

แน่นอนว่าอาจเป็น (?) ไม่ได้ใช้กับ Unity 2.0 ซึ่งวางจำหน่ายในเดือนพฤษภาคม 2010

หวังว่าคนอื่นสามารถให้การเปรียบเทียบตามประสบการณ์โดยตรง


2
ความสามัคคีเป็นสิ่งที่ดีงาม ครอบคลุมมากที่สุดของสิ่งที่ต้องการแม้ว่าบางคนบ่นเกี่ยวกับมันไม่แก้ไขการอ้างอิงแบบวงกลม ฉันรักมัน. ฉันทำทุกอย่างที่ฉันต้องการ
Dmitri Nesteruk

ผู้พัฒนาจำนวนมากใช้Castle.Windsorโดยที่ไม่รู้ตัว เริ่มต้น IOC สำหรับNHibernate (อย่างน้อยกับ FluentNHibernate i downloded เมื่อวานนี้) ฉันเห็นการใช้งาน NHibernate ที่ใช้ LinFu nstead
k3b

5

ดูการเปรียบเทียบnet-ioc-framework บน google codeรวมถึง linfu และ spring.net ที่ไม่ได้อยู่ในรายการของคุณขณะที่ฉันเขียนข้อความนี้

ฉันทำงานกับ spring.net: มันมีคุณสมบัติมากมาย (aop, ไลบรารี, docu, ... ) และมีประสบการณ์มากมายใน dotnet และ java-world คุณสมบัติดังกล่าวได้รับการทำให้เป็นโมดูลดังนั้นคุณจึงไม่จำเป็นต้องใช้คุณสมบัติทั้งหมด คุณสมบัติที่เป็นนามธรรมของปัญหาที่พบบ่อยเช่นการดึงข้อมูลฐานข้อมูลการเข้าสู่ระบบ อย่างไรก็ตามมันเป็น difficuilt ที่ต้องทำและดีบัก IoC- การกำหนดค่า

จากสิ่งที่ฉันได้อ่านจนถึงตอนนี้: ถ้าฉันต้องเลือกโครงการเล็กหรือกลางฉันจะใช้ ninject ตั้งแต่ ioc-configuration เสร็จสิ้นและ debuggable ใน c # แต่ฉันยังไม่ได้ทำงานกับมันเลย สำหรับระบบโมดูลาร์ขนาดใหญ่ฉันจะอยู่กับ spring.net เพราะสิ่งที่เป็นนามธรรม

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