Я готую презентацію для групи користувачів. Як такий, я просто пережив купу їх. А саме: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity та Windsor.
Я хотів продемонструвати 90% випадків (конструкторська ін'єкція, яка в основному використовується людьми МОК).
Ви можете переглянути рішення тут (VS2008)
Таким чином, є кілька ключових відмінностей:
- Ініціалізація
- Пошук об'єктів
Кожен з них також має інші функції (деякі мають AOP і кращі штучки, але я хочу, щоб IOC - це створювати та отримувати для мене об'єкти)
Примітка: відмінності між пошуком об'єктів різних бібліотек можна усунути за допомогою CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator
Це дає нам ініціалізацію, яка робиться двома способами: за допомогою коду або через конфігурацію XML (app.config / web.config / custom.config). Деякі підтримують обоє, деякі підтримують лише одне. Слід зазначити: деякі атрибути використовують, щоб допомогти ІОК.
Тож ось моя оцінка відмінностей:
Ініціалізація коду (лише з атрибутами). Сподіваюся, вам подобаються лямбда. Код ініціалізації виглядає приблизно так:
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 використовує атрибути.
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 через подібність між .net версією Spring.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 та найбільшу гнучкість при ініціалізації.
Примітка : Кріс Брандсма перетворив свою оригінальну відповідь у допис у блозі .