Castle学习笔记之Windsor(二)

最近琐事繁多,以至于这个系列的第二篇文章都迟迟未出,-_-!!
今天特定花点时间来完成它.

我们接着上篇进行一些深入的分析.
首先是构造注入,在Windsor中,我们获取的一个对象实例的代码大致如下:

IWindsorContainer container = new WindsorContainer("../../test.xml");
container.AddComponent("test", typeof(TestObj));
TestObj obj = (TestObj)container["test"];

配置文件如下:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <components>
    <component id="test">
      <parameters>
        <key>key</key>
      </parameters>
    </component>
  </components>
</configuration>

具体上面的代码是什么意思,在上篇文章已经写的比较清楚了,这里就不再多说,现在我们开始分析,为什么只是单单的一个AddComponent就可以直接获取对象实例了.

很自然的,我们从AddComponent函数入手分析.在Container里只有简单的:_kernel.AddComponent
看来这只是层很浅显的封装,关键操作始终是要在kernel里进行.转入DefaultKernel,因为这里的_kernel只是个接口,从WindsorContainer的默认构造函数:

        public WindsorContainer() : this(new DefaultKernel(), new Installer.DefaultComponentInstaller())
        {
        }

可以很容易看出该接口的实例是个DefauleKernel对象.
进入它的AddComponent函数查看,发现只有几行子代码,又是封装.在大型的框架里,为了保持整体结构的完整即使一个很小的功能也会有若干层嵌套,这会给设计者以后的扩展提供便利同时也会给学习者增加难度,我们就耐着性子一步步往下看吧:)

        public virtual void AddComponent(String key, Type classType)
        {
            if (key == null) throw new ArgumentNullException("key");
            if (classType == null) throw new ArgumentNullException("classType");

            ComponentModel model = ComponentModelBuilder.BuildModel(key, classType, classType, null);
            RaiseComponentModelCreated(model);
            IHandler handler = HandlerFactory.Create(model);
            RegisterHandler(key, handler);
        }

这里包含了许多信息,不过我们只关注组件创建时的构造函数的参数如何注入,因此我们分析ComponentModel那句.
这里面出现的ComponentModelBuilder派生自IComponentModelBuilder接口,所有的组件模型构造器都必须从该接口派生,其本身包含了AddContribuitor,RemoveContribuitor和BuildModel方法.这里的ComponentModelBuilder是DefaultComponentModelBuilder的实例对象,除了上述的三个方法外,还额外的添加了InitializeContributors方法用于添加默认的Contributors.该方法如下:

                protected virtual void InitializeContributors()
        {
            AddContributor( new ConfigurationModelInspector() );//
            AddContributor( new LifestyleModelInspector() );
            AddContributor( new ConstructorDependenciesModelInspector() );
            AddContributor( new PropertiesDependenciesModelInspector() );
            AddContributor( new MethodMetaInspector() );
            AddContributor( new LifecycleModelInspector() );
            AddContributor( new ConfigurationParametersInspector() );
            AddContributor( new InterceptorInspector() );
        }

这里我们只关心AddContributor( new ConstructorDependenciesModelInspector() );也就是构造函数依赖的处理.
这句把该模块的处理加入到contributors队列中.返回到BuildModel函数,出现了我们希望看到的关键性代码:

            foreach(IContributeComponentModelConstruction contributor in contributors)
            {
                contributor.ProcessModel( kernel, model );
            }

以前已经说了,构造函数依赖关系的处理已经被加入contributors队列,接下来,我们开始进入ConstructorDependenciesModelInspector的ProcessModel方法进行分析.

        public virtual void ProcessModel(IKernel kernel, ComponentModel model)
        {
            if (converter == null)
            {
                converter = (ITypeConverter) 
                    kernel.GetSubSystem( SubSystemConstants.ConversionManagerKey );
            }

            Type targetType = model.Implementation;

            ConstructorInfo[] constructors = 
                targetType.GetConstructors(BindingFlags.Public|BindingFlags.Instance);

            foreach(ConstructorInfo constructor in constructors)
            {
                // We register each public constructor
                // and let the ComponentFactory select an 
                // eligible amongst the candidates later

                model.Constructors.Add( CreateConstructorCandidate(constructor) );
            }
        }

终于看到了熟悉的反射!函数本身结构很清晰,首先取出所有的构造函数,然后循环,同时给ConstructorCandidate对象赋值,这是个包含了构造信息和依赖模块的对象(该对象包含了构造函数的参数信息).

到此为止,组件的添加过程中与构造函数参数注入有关的部分就结束了,虽然有了个轮廓,但是关键的注入部分始终还没出现,别急,我们接着往下看:)
我们直接返回到最前端,TestObj obj = (TestObj)container["test"];将真正的创建实例,这之前,TestObj对象一直都是处于未激活状态.继续trace…
容器的索引直接被指向_kernel的索引,

        public virtual object this[String key]
        {
            get
            {
                if (key == null) throw new ArgumentNullException("key");

                if (!HasComponent(key))
                {
                    throw new ComponentNotFoundException(key);
                }

                IHandler handler = GetHandler(key);

                return ResolveComponent(handler);
            }
        }

激活的关键就在ResolveComponent函数,进入后才发现,需要转入DefaultHandler的Resolve进行处理,当依赖条件满足时即创建对象所依赖的对象是否都已经激活时,将进入生命周期管理器的Resolve函数进行处理.接下来的调用关系比较复杂,我简单描述一下调用关系:
AbstractLifestyleManager.Resolve()->IComponentActivator.Create()->派生自AbstractComponentActivator的某类->InternalCreate()->Instantiate()
这里停下来了,因为最关键的注入就在这里了,我们开始仔细分析

        protected virtual object Instantiate()
        {
            ConstructorCandidate candidate = SelectEligibleConstructor();
    
            Type[] signature;
            object[] arguments = CreateConstructorArguments( candidate, out signature );
    
            return CreateInstance(arguments, signature);
        }

首先是取出之前生成的ConstructorCandidate对象,然后进入CreateConstructorArguments函数,从下面的返回我们已经可以断定注入就在这个函数里.
CreateConstructorArguments

        protected virtual object[] CreateConstructorArguments( ConstructorCandidate constructor, out Type[] signature )
        {
        //
            foreach(DependencyModel dependency in constructor.Dependencies)
            {
                object value = Kernel.Resolver.Resolve(Model, dependency);
                arguments[index] = value;
                signature[index++] = dependency.TargetType;
            }

            return arguments;
        }

里面我省略了些代码,关键的部分就是这个循环,由object value = Kernel.Resolver.Resolve(Model, dependency);取出了指定的依赖参数的值,生成数组返回,最后CreateInstance…
终于看到了对象的实例化,构造函数的注入的过程已经全部清晰了!
在使用Windsor的容器注册并消除耦合的简单之下,却隐藏着如此深刻的背景,Castle的结构的复杂可见一斑…

到这,本来还想继续介绍些组件的注册方式和参数的配置问题,不过发现本篇的篇幅已经够长了,-_-!,那就留到下篇再写吧:)

PS:说几句题外话,在该系列的第一篇文章里,有朋友问到Castle的性能问题,我想说的是,您看完这篇文章,应该心中就有数了吧?大型的框架专注的是企业级应用和快速开发,如果您的项目需要非常短的响应时间,那么这种类型的框架往往都是不适应的,当然,Castle本身的优秀是不容置疑的,只不过各种框架都有其适用的范围和方向,我们在开发中一定要根据实际情况来判断使用何种方式.(为了写这篇文章,加班了半小时啊,各位看完的朋友一定多多提意见那)