使用Enterprise Library Unity与其他IoC容器(Windsor,Spring.Net,Autofac ..)的优缺点是什么?
使用Enterprise Library Unity与其他IoC容器(Windsor,Spring.Net,Autofac ..)的优缺点是什么?
Answers:
我正在为用户组准备演示文稿。因此,我只是经历了一堆。即: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。
因此,这是我对差异的评估:
仅代码初始化(带有属性)。希望您喜欢lambda。初始化代码如下所示:
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也很lambda'y。总而言之,这是我的最爱之一。有关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配置很麻烦。微软或高速公路商店的好图书馆。代码初始化很容易:
container.RegisterType<ICustomerRepository, CustomerRepository>()
.RegisterType<ICustomerService, CustomerService>();
我只能说XML。但是对于功能性,Spring.Net在IoC可以做的所有事情都在阳光下进行。但是,由于唯一的统一方法是通过XML,因此.net shop通常避免使用它。虽然,由于.net版本的Spring.Net与Java Spring项目之间的相似性,许多.net / Java商店都使用Spring.Net。
注意:现在可以通过引入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语言功能的最佳支持,并且在初始化方面具有最大的灵活性。
注意:克里斯·布兰德斯玛(Chris Brandsma)将他的原始答案变成了博客文章。
旧线程,但是由于这是Google在我输入unity vs spring.net时向我展示的第一件事...
如果您不喜欢XML配置,Spring会立即执行CodeConfig
http://www.springframework.net/codeconfig/doc-latest/reference/html/
而且,Spring不仅仅是一个DI容器,如果您查看文档中的“模块”部分,那么DI容器是它所做的大量工作的基础。
如果我弄错了,请纠正我,但我认为Autofac本身支持XML配置,如以下链接中所列:Autofac XML配置
需要注意的一件事:Ninject是唯一支持上下文依赖项注入的IoC容器(根据其网站)。但是,由于我没有其他IoC容器的经验,因此无法确定是否成立。
为了增加我的2美分,我尝试了StructureMap和Unity。我发现StructureMap的文档很少/有误导性,在配置时很麻烦,而且使用起来很笨拙。同样,它似乎不支持诸如在解析时重写构造函数参数之类的方案,这对我来说是一个关键用法。所以我放弃了它,选择了Unity,并在大约20分钟的时间内完成了我想要的工作。
我个人使用Unity,但这仅是因为它来自Microsoft。我为这个决定感到遗憾是有原因的:它所针对的最大问题是有一个大“ bug”,导致其不断抛出异常。您可以在调试时忽略异常。但是,如果在应用程序上运行它,则会极大地减慢您的应用程序的速度,因为抛出异常是一项昂贵的操作。例如,我目前正在代码中的某个位置“修复”此异常,在该位置Unity的异常使页面的渲染时间增加了4秒。有关更多详细信息和解决方法,请参阅: