标签:
想要将autofac集成到你的应用程序中需要经过如下步骤:
1、使用控制翻转(IoC)的思想架构你的应用程序;
2、添加autofac引用;
3、在应用程序入口...(At application startup...);
4、创建一个ContainerBuilder对象;
5、注册组件;
6、为以后的使用,生成并保存容器;
7、在应用执行期间...(During application execution...);
8、从容器中创建一个生命周期域;
9、使用生命周期域解析(resolve)组件实例。
这个入门指导将带领你通过一个简单的控制台应用程序来完成以上这些步骤。一旦你掌握了这些基础知识,就可以进一步学习更高级的概念以及如何将autofac集成到WCF、ASP.NET或其他类型的应用程序中。
1.1、构建应用(Structuring the Application)
控制反转背后的思想是,与其将应用中的类捆绑到一起从而提升相互间的依赖关系,不如在类被构造时再通过注入的方式引入相关的依赖。如果你想更深入了解控制反转,马丁福勒有一篇优秀的文章解释了依赖注入/控制反转。
在我们的控制台应用程序示例中,我将定义一个输出当前日期的类。但是我们并不想将他直接与控制台绑定,因为我们可能希望在今后能够对这个类进行测试或者将该类应用到控制台意外的地方。
我会尽可能的对输出日期的方式进行抽象,以便于今后我们能够使用其他的版本替换他。
我将会这样设计我们的类:
1 namespace DemoApp 2 { 3 //接口帮助我们将“输出"从控制台类解耦, 4 //我们并不关心输出操作是如何执行的,只要能输出就够了。 5 public interface IOutput 6 { 7 void Write(string content); 8 } 9 10 //ConsoleOuput实现了IOutput接口, 11 //他将信息写到了控制台。从技术上来说我们还可以通过 12 //实现IOutput接口,将信息写入跟踪调试或者其他地方 13 public class ConsoleOutput : IOutput 14 { 15 public void Write(string content) 16 { 17 Console.WriteLine(content); 18 } 19 } 20 21 //这个接口解耦了输入日期的机制,与IOutput一样,实际的处理机制 22 //通过接口进行了抽象 23 public interface IDateWriter 24 { 25 void WriteDate(); 26 } 27 28 //注意TodayWriter定义了一个使用IOutput作为形参的构造函数, 29 //这样做可以根据传入的具体具体类型将日期写到任何地方,他实现了 30 //WriteDate()方法来输入日期,你可以让他以不同的格式输出到 31 //不同的地方 32 public class TodayWriter : IDateWriter 33 { 34 private IOutput _output; 35 public TodayWriter(IOutput output) 36 { 37 this._output = output; 38 } 39 public void WriteDate() 40 { 41 this._output.Write(DateTime.Today.ToShortDateString()); 42 } 43 } 44 }
现在我们有一个合理的结构来设置依赖关系,那就让我们通过autofac来将他们结合到一起吧!
1.2、添加autofac引用
第一步是将autofac添加到你的应用。在这个应用中我们只是用core autofac(这里翻译成核心autofac感觉怪怪的,直接上英文还显得明了一些),其他的应用类型可以使用额外的Autofac integration libraries。
最简单的方式是通过NuGet来添加autofac引用,”Autofac"包已经包含了你需要的所有核心功能。
1.3、应用程序入口
在应用程序入口你需要创建一个ContainerBuilder,并将组件注册到其中。组件可能是一个表达式、.net类型或者其他的暴露了一个或多个服务并能够被其他依赖项所使用的代码。简单来说,可以将组件理解为实现了某个接口的.net类型,列如:
public class SomeType : IService { }
你可以通过两种方式来识别它:一种方式可以将其看作本身的类型(SomeType),另一种可以将其视为接口(IService)。在这种情况下组件就是SomeType,而其所暴露的服务就是SomeType和IService。
在autofac中,你需要将其注册到ContainerBuilder中,比如:
//创建ContainerBuilder对象 var builder = new ContainerBuilder(); //通常情况下你所感兴趣的是组件通过接口暴露的服务 builder.RegisterType<SomeType>().As<IService>(); //然而如果你同时也对组件通过自身类型暴露的服务感兴趣(并不常见),可以如下方式进行注册: builder.RegisterType<SomeType>().AsSelf().As<IService>();
在我们的应用中,需要对我们所有的组件(class)进行注册,并暴露他们所提供的服务(Interface)。
我们同样需要保存我们容器,以便于之后通过容器来解析类型。
using System; using Autofac; namespace DemoApp { public class Program { private static IContainer Container{ get; set; } static void Main(string[] args) { var builder = new ContainerBuilder(); builder.RegisterType<ConsoleOutput>().As<IOutput>(); builder.RegisterType<TodayWrite>().As<IDateWrite>(); Container = builder.Build(); //我们将在WriteDate方法中使用依赖注入,该方法我们稍后实现。 WriteDate(); } } }
现在,我们已经拥有了容器,注册了组件并暴露了适当的服务,现在就让我们来使用它。
1.4、应用的执行
在应用执行时,你需要使用注册的组件。为此,将从一个生命周期域中解析组件。
容器本身是一个生命周期域,技术上来说,你可以直接通过容器进行解析。然后这样的做法是不被推荐的。
当你解析一个组件,根据你定义的实例范围,一个新的对象实例将被创建。(解析一个组件大致等效于“new”一个类的实例,这是最最简化的一种说法,但从比喻的角度来看却是很恰当的。)一些组件可能需要被销毁(比如实现了IDisposable接口的组件),当生命周期域被释放的时候autofac能够帮你处理这些组件。
然而,container存在于你的应用程序生命周期中,如果你直接从容器中解析了很多的组件,最终将会有很多的组件实例等待销毁。这很糟糕(这可能会导致内存溢出)。
相反,从container中创建子生命周期域,并从子生命周期域中解析组件,那么当子生命周期域结束时所有从该域中创建的组件都将被销毁。(当你使用Autofac integration libraries时,创建子生命周期域的任务将由autofac完成,你不必过多考虑)
在我们的例子中,我将实现WriteDate方法,在一个域中执行输出,并在完成后销毁该域。
namespace DemoApp { public class Program { private IContainer Container{ get; set; } static void Main(string[] args) { // ...the stuff you saw earlier... } public static void WriteDate() { //创建域,解析IDateWriter using(var scope = Container.BeginLifetimeScope()) { var writer = scope.Resolve<IDateWriter>(); writer.WriterDate(); } } } }
现在当你运行程序时:
1、“WriteDate”方法向autofac请求一个IDateWtiter;
2、autofac发现IDateWtiter映射到TodayWriter,然后创建TodayWriter对象;
3、autofac发现TodayWriter的构造函数需要一个IOutput参数;
4、autofac发现IOutput映射到ConsoleOutput,然后创建ConsoleOutput实例;
5、autofac使用ConsoleOutput实例完成TodayWriter的创建工作;
6、autofac完成TodayWriter创建,并将TodayWriter实例返回给“WriteDate”。
以后,如果你希望你的应用程序输出不同的日期,你可以实现不同的IDateWriter并修改应用程序入口处的注册,这样你就不必在修改其他的类。耶,控制反转!!
注意:一般来说,服务定位很大程度上被视为一种“反模式”,也就是说到处都通过手动创建域(scope)以及直接使用container并不是最好的选择。使用Autofac integration libraries通常不需要我们去手动的完成示例应用程序中创建域以及解析组件的工作,在应用程序中“顶层”定位以及手动解析组件是非常罕见的,当然,如何设计你的应用程序取决于你自己。
PS:本系列博客是对autofac官方文档的翻译,主要目的是为了提高自己英文阅读能力,同时能够帮助有需要的人,原文地址http://autofac.readthedocs.org/en/latest/getting-started/index.html。翻译过程中我将“resolve”译为“解析”,但在阅读中感觉意思并未通达,绞尽脑汁仍未找到恰当的词语代替,若各位园友有合适翻译还望指教。
标签:
原文地址:http://www.cnblogs.com/Colorful-MrC/p/autofac.html