Castle IOC容器实践之Startable Facility(二)

主要内容

Startable Facility原理分析

……

在Castle IOC容器实践之Startable Facility(一)中我们已经看到了如何去使用Startable Facility,本文将对它的原理做一些分析。先看一下接口IStartable,它的实现代码如下:

public interface IStartable
{
  void Start();
  void Stop();
}

代码是相当的简单,只有两个方法,分别在组件创建的时候和销毁的时候执行,这就涉及到了组件的生命周期管理。在Windsor中,接口ILifecycleConcern提供特定的组件生命周期管理:

public interface ILifecycleConcern
{
  void Apply( ComponentModel model, object component );
}

现在我们要实现组件的自动创建和销毁,就需要实现接口ILifecycleConcern,在Startable Facility中分别用两个类来实现,第一个类StartConcern,它判断如果组件实现了接口IStartable,则直接调用它的Start()方法;如果组件是用特性startMethod,则获取并调用具有startMethod特性的方法:
public class StartConcern : ILifecycleConcern
{
  private static readonly StartConcern _instance = new StartConcern();
  protected StartConcern()
  {
  }
  public static StartConcern Instance
  {
    get { return _instance; }
  }
  public void Apply(ComponentModel model, object component)
  {
    if (component is IStartable)
    {
      (component as IStartable).Start();
    }
    else if (model.Configuration != null)
    {
      String startMethod = model.Configuration.Attributes["startMethod"];
      if (startMethod != null)
      {
        MethodInfo method = model.Implementation.GetMethod(startMethod);
        method.Invoke(component, null);
      }
    }
  }
}

时间: 2024-12-03 22:28:39

Castle IOC容器实践之Startable Facility(二)的相关文章

Castle IOC容器实践之Startable Facility(一)

主要内容 1.Startable Facility概述 2.实现IStartable接口使用详解 3.不实现IStartable接口使用 一.Startable Facility概述 在开始使用Startable Facility之前,我们先了解一下它做了什么事情,它可以让一个组件在满足依赖关系之后自动启动或者停止.官方网站中提供的Startable Facility的有关信息: Facility Information Uses Proxy No Requires Configuration

Castle IOC容器实践之TypedFactory Facility(一)

主要内容 1.TypedFactory Facility概述 2.TypedFactory Facility快速入门 一.TypedFactory Facility概述 相信大家对于Factory Method设计模式都已经不陌生了,在Factory Method中,对于每一个具体的产品都需要有一个与之对应的工厂类,随着具体的产品越来越多,我们对于工厂类的管理就越来越困难,那如何通过IOC容器来实现对工厂的管理呢?本文将给你答案.在开始使用之前,我们还是先来看一下Castle官方网站中给出的有关

Castle IOC容器实践之TypedFactory Facility(二)

主要内容 TypedFactory Facility原理分析 -- 在TypedFactory Facility中,有一个FactoryEntry类,这个类与我们平时项目开发中的实体类有一些类似,它用来记录工厂的相关信息,包括工厂的ID,工厂的接口,创建方法和销毁方法.这个类实现如下: public class FactoryEntry { private String _id; private Type _factoryInterface; private String _creationMe

Castle IOC容器实践之FactorySupport Facility

它使用了以下两种处理策略: 1.使用访问器来访问组件的实例 2.使用静态方法或者实例方式来访问组件的实例 主要内容 1.概述 2.为什么需要FactorySupport Facility 3.如何使用 4.常见的配置示例 5.实现原理浅析 一.概述 FactorySupport Facility允许我们使用已经存在的工厂来创建组件的实例,可以把已经存在的对象模型加入到容器中,以便它能够使用自动装配.它使用了以下两种处理策略: 1.通过访问器来访问组件的实例 2.通过静态方法或者实例方式来访问组件

Castle IOC容器实践之EnterpriseLibrary Configuration Facility

主要内容: 1.概述 2.使用Facility 3.原理浅析 一.概述 EnterpriseLibrary Configuration Facility就好像是在容器和数据类之间的桥,让我们可以轻松得去读取和操作配置文件.熟悉Enterprise Library的人都知道,在Enterprise Library中有一个Configuration Application Block,它可以使我们方便的从各种存储中读写配置信息,通过EnterpriseLibrary Configuration Fa

Castle IOC容器快速入门

主要内容 1.为什么要IOC 2.什么是Castle IOC容器 3.快速入门示例 4.几个重要的概念 一,为什么要IOC IOC(控制反转或者叫依赖注入)Martin Fowler大师在他的文章中已经讲解的非常精彩了,这里实在不敢班门弄斧,只好简单地解释几句.我们使用抽象接口来隔离使用者和具体实现之间的依赖关系,但是不管再怎么抽象,最终还是要创建具体实现类的实例,这种创建具体实现类的实例对象就会造成对于具体实现的依赖,为了消除这种创建依赖性,需要把依赖移出到程序的外部(比如配置文件).使用依赖

Castle IOC容器与Spring.NET配置之比较

我本人对于Spring.NET并不了解,本文只是通过一个简单的例子来比较一下两者配置之间的区别.在Castle IOC容器中,提出了自动装配(Auto-Wiring)的概念,即由容器自动管理组件之间的依赖关系,我们无需自己编写XML配置文件来配置组件之间的依赖关系.在Spring.NET中也是支持自动装配的,但是并不推荐使用,它贯穿着一种思想就是一切皆为XML配置,这是两者之间最大的一个区别. 关于自动装配,来自于Spring.NET的支持者认为让容器自动管理,会让我们无法控制组件的依赖关系,如

Castle IOC容器组件生命周期管理

主要内容 1.生命处理方式 2.自定义生命处理方式 3.生命周期处理 一.生命处理方式 我们通常创建一个组件的实例使用new关键字,这样每次创建出来的都是一个新的实例,如果想要组件只有一个实例,我们会使用Singleton模式.在Castle IOC中,它支持我们对于组件的实例进行控制,也就是说我们可以透明的管理一个组件拥有多少个实例.Castle IOC容器提供了如下几种生命处理方式: l Singleton:一个组件只有一个实例被创建,所有请求的客户使用程序得到的都是同一个实例,同时这也是C

Castle IOC容器构建配置详解(二)

主要内容 1.基本类型配置 2.Array类型配置 3.List类型配置 4.Dictionary类型配置 5.自定义类型转换 一.基本类型配置 在Castle IOC的配置文件中,大家可能都已经注意一个问题了,就是不管组 件接收的是什么基本数据类型,我们一律没有在配置文件中指定,也就是说,不 管组件接收的类型是int型或者是String类型,我们都可以这样去配置: <component id="MyComponent"> <parameters> <po