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

主要内容

1.生命处理方式

2.自定义生命处理方式

3.生命周期处理

一.生命处理方式

我们通常创建一个组件的实例使用new关键字,这样每次创建出来的都是一个新的实例,如果想要组件只有一个实例,我们会使用Singleton模式。在Castle IOC中,它支持我们对于组件的实例进行控制,也就是说我们可以透明的管理一个组件拥有多少个实例。Castle IOC容器提供了如下几种生命处理方式:

l Singleton:一个组件只有一个实例被创建,所有请求的客户使用程序得到的都是同一个实例,同时这也是Castle IOC容器默认的一种处理方式。

l Transient:这种处理方式与我们平时使用new的效果是一样的,对于每次的请求得到的都是一个新的实例。

l PerThread:对于每一个线程来说是使用了Singleton,也就是每一个线程得到的都是同一个实例。

l Pooled:对象池的处理方式,对于不再需用的实例会保存到一个对象池中。

l Custom:自定义的生命处理方式。

我们可以通过以下两种方式来指定组件的生命处理方式,如果不指定,则为Singleton方式:

1.使用配置文件

<!--出处:http://terrylee.cnblogs.com-->
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <components>
    <component id="comp1" lifestyle="transient">
      <parameters>
        <para>component1 para</para>
      </parameters>
    </component>>
  </components>
</configuration>

2.使用Attribute特性

//出处:http://terrylee.cnblogs.com
[Transient]
public class MyComponent
{
  public MyComponent()
  {
    //
  }
  public MyComponent(string _Str)
  {
    //
  }
}

时间: 2024-10-28 13:26:17

Castle IOC容器组件生命周期管理的相关文章

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

主要内容 Startable Facility原理分析 -- 在Castle IOC容器实践之Startable Facility(一)中我们已经看到了如何去使用Startable Facility,本文将对它的原理做一些分析.先看一下接口IStartable,它的实现代码如下: public interface IStartable { void Start(); void Stop(); } 代码是相当的简单,只有两个方法,分别在组件创建的时候和销毁的时候执行,这就涉及到了组件的生命周期管理

TOMCAT源码分析——生命周期管理(一)

前言 从server.xml文件解析出来的各个对象都是容器,比如:Server.Service.Connector等.这些容器都具有新建.初始化完成.启动.停止.失败.销毁等状态.tomcat的实现提供了对这些容器的生命周期管理,本文将通过对Tomcat7.0的源码阅读,深入剖析这一过程. TOMCAT生命周期类接口设计 我们先阅读图1,从中了解Tomcat涉及生命周期管理的主要类. 图1 Tomcat生命周期类接口设计 这里对图1中涉及的主要类作个简单介绍: Lifecycle:定义了容器生命

自定义Unity对象生命周期管理集成ADO.NET Entity Framework

在Unity中,从Unity 取得的实例为 Transient.如果你希望使用多线程方式,就需要在组成时使用lifecycle参数,这时候取出的组件就不再是同一个了.在Unity IOC中,它支持我们对于组件的实例进行控制,也就是说我们可以透明的管理一个组件拥有多少个实例.Unity IOC容器提供了如下几种生命处理方式:# Singleton:一个组件只有一个实例被创建,所有请求的客户使用程序得到的都是同一个实例.# Transient:这种处理方式与我们平时使用new的效果是一样的,对于每次

Castle IOC容器内幕故事(下)

主要内容 1.ComponentModelBuilder 和 Contributors 2.Contributors分析 3.Handles分析 4.ComponentActivator分析 一.ComponentModelBuilder 和 Contributors 在前一篇中介绍组件的注册流程时说到了,创建ComponentModel的过程就是调用contributor来对组件进行处理的过程.Contributor就是我们这个内幕故事的第一个主角,在DefaultComponentModel

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

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

TOMCAT源码分析——生命周期管理(二)

前言 我在<TOMCAT源码分析--生命周期管理(一)>一文中介绍了TOMCAT生命周期类接口设计.JMX.容器以及基于容器的事件与监听等内容,本文将接着介绍Tomcat7.0中容器生命周期的管理. 容器生命周期 每个容器都会有自身的生命周期,其中也涉及状态的迁移,以及伴随的事件生成,本节详细介绍Tomcat中的容器生命周期实现.所有容器的转态转换(如新疆.初始化.启动.停止等)都是由外到内,由上到下进行,即先执行父容器的状态转换及相关操作,然后再执行子容器的转态转换,这个过程是层层迭代执行的

Castle IOC容器快速入门

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

ASP.NET Core中的依赖注入(4): 构造函数的选择与服务生命周期管理

ServiceProvider最终提供的服务实例都是根据对应的ServiceDescriptor创建的,对于一个具体的ServiceDescriptor对象来说,如果它的ImplementationInstance和ImplementationFactory属性均为Null,那么ServiceProvider最终会利用其ImplementationType属性返回的真实类型选择一个适合的构造函数来创建最终的服务实例.我们知道服务服务的真实类型可以定义了多个构造函数,那么ServiceProvid

四个问题读懂阿里云的镜像仓库,如何为镜像进行全生命周期管理?

一句话介绍镜像仓库 阿里云容器镜像服务提供了安全的镜像托管能力,稳定的国内外镜像构建服务.便捷的团队组织协作功能等,方便用户进行镜像的全生命周期管理. 下面是阿里云容器镜像服务的相关数字: 经过阿里集团双十一验证,支撑10万镜像.2亿下载.近万并发 为什么推出镜像仓库? 容器的使用离不开镜像.以Docker为代表的容器技术,可以将应用打包成标准格式的镜像,并且应用会以容器的方式再度启用运行. 在真正的生产环境中,你会需要大量的镜像,第三方或者是自建的:大量镜像伴随而来的是需要保存.分发使用等管控