依赖注入容器Autofac
本文内容纲要:依赖注入容器Autofac
在.NET上现在存在许多的依赖注入容器, 我也在实践中使用过Castle Windsor、StructureMap、Autofac 、Unity**。**这些容器的简要介绍可以参看:
IoC in .NET part 1: Autofac
IoC in .NET part2: StructureMap
IoC in .NET part 3: Ninject 2 beta
IoC in .NET part4: Spring.NET
IoC in .NET part 5: Using CastleWindsor container
IoC Containers in .NET part 6: Unity Container
这里主要介绍一下Autofac,Autofac和其他容器的不同之处是它和C#语言的结合非常紧密,在使用过程中对你的应用的侵入性几乎为零,更容易与第三方的组件集成。Autofac的主要特性如下:
- 灵活的组件实例化:Autofac支持自动装配,给定的组件类型Autofac自动选择使用构造函数注入或者属性注入,Autofac还可以基于lambda表达式创建实例,这使得容器非常灵活,很容易和其他的组件集成。
var defaultLog = new ConsoleLog(); builder.Register(c => new Connection(){ Log = c.ResolveOptional<ILog>() ?? defaultLog });
大家知道lambda表达式并不是在声明的时候的执行的,只有等到容器的Resolve()方法调用的时候,表达式才执行。表达式还有一个好处是不需要使用反射或者是使用XML语法来表达。 - 资源管理的可视性:基于依赖注入容器构建的应用程序的动态性,意味着什么时候应该处理那些资源有点困难。Autofac通过跟踪特定作用域内的实例和依赖来解决这个问题(DeterministicDisposal)。IDisposable接口接口是把双刃剑,既是一个老孙手上的金箍棒,也是老孙头上的魔咒,有一种明确的方式告诉那一部分应该被清理,但是一个组件要何时处理并不是很容易确定的事情,比如说一个服务可以有多个实现的时候就变得很糟糕,组件的创建上(GOF的创建型设计模式)有的是通过工厂方式创建的,有的是单件方式创建的,有些需要被清理,有些却不需要清理。组件的使用者无法知道是否把转换为IDisposable接口调用它的Disposal方法。Autofac通过容器来跟踪组件的资源管理。对于不需要清理的对象,例如Console.Out,我们调用ExternallyOwned()方法告诉容器不用清理。细粒度的组件生命周期管理:应用程序中通常可以存在一个应用程序范围的容器实例,在应用程序中还存在大量的一个请求的范围的对象,例如一个HTTP请求,一个IIS工作者线程或者用户的会话结束时结束。通过嵌套的容器实例和对象的作用域使得资源的可视化。
- Autofac的设计上非常务实,这方面更多是为我们这些容器的使用者考虑:
- 组件侵入性为零:组件不需要去引用Autofac。
- 灵活的模块化系统:通过模块化组织你的程序,应用程序不用纠缠于复杂的XML配置系统或者是配置参数。
- 自动装配:可以是用lambda表达式注册你的组件,autofac会根据需要选择构造函数或者属性注入
- XML配置文件的支持:XML配置文件过度使用时很丑陋,但是在发布的时候通常非常有用
- 组件的多服务支持:许多设计师喜欢使用细粒度的接口来控制依赖 , autofac允许一个组件提供多个服务。
Autofac的目前稳定版本是1.4,支持.NET和Silverlight应用程序。2.1版本目前处于Beta状态,2.1版本相对于1.4版本做了些调整,可以参照http://code.google.com/p/autofac/wiki/NewInV2,如果你对Autofac感兴趣,尽快开始Autofac之旅吧,可以给你不一样的思路。
autofac文档
http://alexmg.com/?tag=/autofac
http://www.lanwin.de/2010/07/20/why-i-moved-from-windsor-to-autofac/
AutoFac使用方法总结:Part III
AutoFac使用方法总结:Part II
AutoFac使用方法总结:Part I
本文内容总结:依赖注入容器Autofac
原文链接:https://www.cnblogs.com/shanyou/archive/2010/02/07/1665451.html
以上是 依赖注入容器Autofac 的全部内容, 来源链接: utcz.com/z/295875.html