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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:
摘要:从本文开始,我们将逐一实践Castle IOC中的Facility,在前面我们说过,Facility它是带有注入性质的。有时我们会遇到这样的问题,当一个组件满足一定的依赖关系之后,让它自动运行,比如说启动一个窗体或者启动某种服务,本文我们就来看如何使用Startable Facility让一个实现了接口IStartable的组件自动运行,以及不实现IStartable接口的组件如何在满足依赖后自动运行。
 
主要内容
1.Startable Facility概述
2.实现IStartable接口使用详解
3.不实现IStartable接口使用
 
一.Startable Facility概述
在开始使用Startable Facility之前,我们先了解一下它做了什么事情,它可以让一个组件在满足依赖关系之后自动启动或者停止。官方网站中提供的Startable Facility的有关信息:
Facility Information
Uses Proxy
No
Requires Configuration
No
Uses Attributes
No
Version
Beta 2
 
二.实现IStartable接口使用详解
Startable Facility的使用可以说是非常地简单,只要我们的组件实现了IStartable接口就可以了。现在我们还有一个Program类,它专门控制Server的启动和停止,我们希望在它的依赖关系满足后,让Server自动启动。很简单,我们让Program类实现IStartable接口:
/// <summary>

/// Author:Terrylee

/// Date:2006年4月28日

/// From:[url]http://terrylee.cnblogs.com[/url]

/// </summary>


public   class  Program : IStartable
{
    
private Server _server;

    
public Program(Server server)
    
{
        
this._server = server;
    }


    
public void Start()
    
{
        _server.Start();
    }


    
public void Stop()
    
{
        _server.Stop();
    }

}

注意这个里面的 Start()和Stop()方法就是要实现接口中的方法,我们在Start()方法中启动服务器,在Stop()方法中停止服务器。并且这个类依赖于Server类,也就是要满足它的依赖关系,还需要有一个Server组件。 服务器Server,它需要一个Host和Port:
/// <summary>

/// Author:Terrylee

/// Date:2006年4月28日

/// From:[url]http://terrylee.cnblogs.com[/url]

/// </summary>


public   class  Server
{
    
private string _host;

    
private int _port;

    
public Server(string host,int port)
    
{
        
this._host = host;

        
this._port = port;
    }


    
public void Start()
    
{
        Console.WriteLine(
"Server {0}:{1} Start",_host,_port);

        Console.ReadLine();
    }


    
public void Stop()
    
{
        Console.WriteLine(
"Server {0}:{1} Stop",_host,_port);

        Console.ReadLine();
    }

}

同时对于这个 Server类来说,它需要一个配置文件:
<!-- From:[url]http://terrylee.cnblogs.com[/url] -->

<? xml version="1.0" encoding="utf-8"  ?>

< configuration >

    
< components >

        
< component  id ="server" >

            
< parameters >

                
< host > localhost </ host >

                
< port > 110 </ port >

            
</ parameters >

        
</ component >

    
</ components >

</ configuration >

需要注意的是这个配置文件跟 Startable Facility没有任何关系,我们在配置文件中看不到任何和Startable Facility有关的代码。它只是一个普通的Castle IOC配置文件,因为我们在概述中已经说过了,Startable Facility是不需要配置文件的。好了,现在我们来看客户程序的使用:
/// <summary>

/// Author:Terrylee

/// Date:2006年4月28日

/// From:[url]http://terrylee.cnblogs.com[/url]

/// </summary>


public   class  App
{
    
public static void Main() 
    
{
        
//创建Windsor容器

        IWindsorContainer container 
= new WindsorContainer(new XmlInterpreter("../../BasicUsage.xml"));        

        
//添加Facility

        container.AddFacility(
"startable"new StartableFacility());       

        
//添加Program组件 (A)

        container.AddComponent(
"program"typeof(Program));      

        
//添加Server组件(B)

        container.AddComponent(
"server"typeof(Server));
    }

}

可以看到,在这个过程中,没有一点多余的代码,首先添加 Startable Facility到容器中,然后添加Program组件,即执行到上面的A句的时候,因为还没有添加Server组件,不满足它的依赖关系,所以它无法启动,当添加完Server组件后,即执行了B句后,满足了它的依赖关系,这个它才会自动执行。
三.不实现IStartable接口使用
这是个很多人都忽略的问题,开始时我一直认为只有实现了 IStartable接口才能使用 Startable Facility,后来我在读它的源码时发现了一个问题,它不仅仅是判断组件是否实现了这个接口,如果组件有Startable特性也可以在满足依赖性后自动启动,这个在下一篇原理分析篇中我会介绍到。然后我就去查找这方面的资料,很可惜的网上从来没有介绍这种使用方法,我从它的TestCase找到了一点下面的代码,供有兴趣的朋友参考一下:
没有实现IStartable接口的组件:
[Transient]

public   class  NoInterfaceStartableComponent
{
    
private bool _Started = false;

    
private bool _Stopped = false;

    
public void Start()
    
{
        _Started 
= true;
    }


    
public void Stop()
    
{
        _Stopped 
= true;
    }


    
public bool Started
    
{
        
get return _Started; }
    }


    
public bool Stopped
    
{
        
get return _Stopped; }
    }

}

测试代码:
[Test]

public   void  TestComponentWithNoInterface()
{
    IKernel kernel 
= new DefaultKernel();


    MutableConfiguration compNode 
= new MutableConfiguration("component");

    compNode.Attributes[
"id"= "b";

    compNode.Attributes[
"startable"= "true";

    compNode.Attributes[
"startMethod"= "Start";

    compNode.Attributes[
"stopMethod"= "Stop";

    kernel.ConfigurationStore.AddComponentConfiguration(
"b", compNode);


    kernel.AddFacility( 
"startable"new StartableFacility() );

    kernel.AddComponent( 
"b"typeof(NoInterfaceStartableComponent) );

    NoInterfaceStartableComponent component 
= kernel["b"as NoInterfaceStartableComponent;


    Assert.IsNotNull(component);

    Assert.IsTrue( component.Started );

    Assert.IsFalse( component.Stopped );
 

    kernel.ReleaseComponent(component);

    Assert.IsTrue( component.Stopped );

}
对于 IKrnel大家可以自行修改为Castle.Windsor,这样也不失为一种使用Startable Facility的方法。













本文转自lihuijun51CTO博客,原文链接:  http://blog.51cto.com/terrylee/67684 ,如需转载请自行联系原作者
相关文章
|
3月前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
168 2
|
2月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
2月前
|
存储 人工智能 调度
容器服务:智算时代云原生操作系统及月之暗面Kimi、深势科技实践分享
容器技术已经发展成为云计算操作系统的关键组成部分,向下高效调度多样化异构算力,向上提供统一编程接口,支持多样化工作负载。阿里云容器服务在2024年巴黎奥运会中提供了稳定高效的云上支持,实现了子弹时间特效等创新应用。此外,容器技术还带来了弹性、普惠的计算能力升级,如每分钟创建1万Pod和秒级CPU资源热变配,以及针对大数据与AI应用的弹性临时盘和跨可用区云盘等高性能存储解决方案。智能运维方面,推出了即时弹性节点池、智能应用弹性策略和可信赖集群托管运维等功能,进一步简化了集群管理和优化了资源利用率。
|
2月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
2月前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
本文源自张凯在2024云栖大会的演讲,介绍了阿里云容器服务在AI智算领域的创新与实践。从2018年推出首个开源GPU容器共享调度方案至今,阿里云容器服务不断推进云原生AI的发展,包括增强GPU可观测性、实现多集群跨地域统一调度、优化大模型推理引擎部署、提供灵活的弹性伸缩策略等,旨在为客户提供高效、低成本的云原生AI解决方案。
|
3月前
|
安全 持续交付 Docker
深入理解并实践容器化技术——Docker 深度解析
深入理解并实践容器化技术——Docker 深度解析
109 2
|
3月前
|
Prometheus 监控 持续交付
深入理解Docker容器化技术:从基础到实践
深入理解Docker容器化技术:从基础到实践
|
3月前
|
安全 Docker 微服务
深入理解Docker容器技术:从基础到实践
深入理解Docker容器技术:从基础到实践
|
3月前
|
Kubernetes Cloud Native Docker
云原生技术探索:容器化与微服务的实践之道
【10月更文挑战第36天】在云计算的浪潮中,云原生技术以其高效、灵活和可靠的特性成为企业数字化转型的重要推手。本文将深入探讨云原生的两大核心概念——容器化与微服务架构,并通过实际代码示例,揭示如何通过Docker和Kubernetes实现服务的快速部署和管理。我们将从基础概念入手,逐步引导读者理解并实践云原生技术,最终掌握如何构建和维护一个高效、可扩展的云原生应用。
|
3月前
|
Cloud Native 持续交付 Docker
Docker容器化技术:从入门到实践
Docker容器化技术:从入门到实践