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接口:
ExpandedBlockStart.gif /// <summary>
InBlock.gif
InBlock.gif
/// Author:Terrylee
InBlock.gif
InBlock.gif
/// Date:2006年4月28日
InBlock.gif
InBlock.gif
/// From:[url]http://terrylee.cnblogs.com[/url]
InBlock.gif
ExpandedBlockEnd.gif
/// </summary>

None.gif
None.gif
public   class  Program : IStartable
ExpandedBlockStart.gif
{
InBlock.gif    
private Server _server;
InBlock.gif
InBlock.gif    
public Program(Server server)
ExpandedSubBlockStart.gif    
{
InBlock.gif        
this._server = server;
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public void Start()
ExpandedSubBlockStart.gif    
{
InBlock.gif        _server.Start();
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public void Stop()
ExpandedSubBlockStart.gif    
{
InBlock.gif        _server.Stop();
ExpandedSubBlockEnd.gif    }

ExpandedBlockEnd.gif}

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

ExpandedBlockStart.gif /// <summary>
InBlock.gif
InBlock.gif
/// Author:Terrylee
InBlock.gif
InBlock.gif
/// Date:2006年4月28日
InBlock.gif
InBlock.gif
/// From:[url]http://terrylee.cnblogs.com[/url]
InBlock.gif
ExpandedBlockEnd.gif
/// </summary>

None.gif
None.gif
public   class  Server
ExpandedBlockStart.gif
{
InBlock.gif    
private string _host;
InBlock.gif
InBlock.gif    
private int _port;
InBlock.gif
InBlock.gif    
public Server(string host,int port)
ExpandedSubBlockStart.gif    
{
InBlock.gif        
this._host = host;
InBlock.gif
InBlock.gif        
this._port = port;
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public void Start()
ExpandedSubBlockStart.gif    
{
InBlock.gif        Console.WriteLine(
"Server {0}:{1} Startdot.gif",_host,_port);
InBlock.gif
InBlock.gif        Console.ReadLine();
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public void Stop()
ExpandedSubBlockStart.gif    
{
InBlock.gif        Console.WriteLine(
"Server {0}:{1} Stopdot.gif",_host,_port);
InBlock.gif
InBlock.gif        Console.ReadLine();
ExpandedSubBlockEnd.gif    }

ExpandedBlockEnd.gif}

同时对于这个 Server类来说,它需要一个配置文件:
None.gif <!-- From:[url]http://terrylee.cnblogs.com[/url] -->
None.gif
None.gif
<? xml version="1.0" encoding="utf-8"  ?>
None.gif
None.gif
< configuration >
None.gif
None.gif    
< components >
None.gif
None.gif        
< component  id ="server" >
None.gif
None.gif            
< parameters >
None.gif
None.gif                
< host > localhost </ host >
None.gif
None.gif                
< port > 110 </ port >
None.gif
None.gif            
</ parameters >
None.gif
None.gif        
</ component >
None.gif
None.gif    
</ components >
None.gif
None.gif
</ configuration >

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

ExpandedBlockStart.gif /// <summary>
InBlock.gif
InBlock.gif
/// Author:Terrylee
InBlock.gif
InBlock.gif
/// Date:2006年4月28日
InBlock.gif
InBlock.gif
/// From:[url]http://terrylee.cnblogs.com[/url]
InBlock.gif
ExpandedBlockEnd.gif
/// </summary>

None.gif
None.gif
public   class  App
ExpandedBlockStart.gif
{
InBlock.gif    
public static void Main() 
ExpandedSubBlockStart.gif    
{
InBlock.gif        
//创建Windsor容器
InBlock.gif

InBlock.gif        IWindsorContainer container 
= new WindsorContainer(new XmlInterpreter("../../BasicUsage.xml"));        
InBlock.gif
InBlock.gif        
//添加Facility
InBlock.gif

InBlock.gif        container.AddFacility(
"startable"new StartableFacility());       
InBlock.gif
InBlock.gif        
//添加Program组件 (A)
InBlock.gif

InBlock.gif        container.AddComponent(
"program"typeof(Program));      
InBlock.gif
InBlock.gif        
//添加Server组件(B)
InBlock.gif

InBlock.gif        container.AddComponent(
"server"typeof(Server));
ExpandedSubBlockEnd.gif    }

ExpandedBlockEnd.gif}

可以看到,在这个过程中,没有一点多余的代码,首先添加 Startable Facility到容器中,然后添加Program组件,即执行到上面的A句的时候,因为还没有添加Server组件,不满足它的依赖关系,所以它无法启动,当添加完Server组件后,即执行了B句后,满足了它的依赖关系,这个它才会自动执行。

三.不实现IStartable接口使用

这是个很多人都忽略的问题,开始时我一直认为只有实现了 IStartable接口才能使用 Startable Facility,后来我在读它的源码时发现了一个问题,它不仅仅是判断组件是否实现了这个接口,如果组件有Startable特性也可以在满足依赖性后自动启动,这个在下一篇原理分析篇中我会介绍到。然后我就去查找这方面的资料,很可惜的网上从来没有介绍这种使用方法,我从它的TestCase找到了一点下面的代码,供有兴趣的朋友参考一下:

没有实现IStartable接口的组件:

None.gif [Transient]
None.gif
None.gif
public   class  NoInterfaceStartableComponent
ExpandedBlockStart.gif
{
InBlock.gif    
private bool _Started = false;
InBlock.gif
InBlock.gif    
private bool _Stopped = false;
InBlock.gif
InBlock.gif    
public void Start()
ExpandedSubBlockStart.gif    
{
InBlock.gif        _Started 
= true;
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public void Stop()
ExpandedSubBlockStart.gif    
{
InBlock.gif        _Stopped 
= true;
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public bool Started
ExpandedSubBlockStart.gif    
{
ExpandedSubBlockStart.gif        
get return _Started; }
ExpandedSubBlockEnd.gif    }

InBlock.gif
InBlock.gif    
public bool Stopped
ExpandedSubBlockStart.gif    
{
ExpandedSubBlockStart.gif        
get return _Stopped; }
ExpandedSubBlockEnd.gif    }

ExpandedBlockEnd.gif}

测试代码:
None.gif [Test]
None.gif
None.gif
public   void  TestComponentWithNoInterface()
ExpandedBlockStart.gif
{
InBlock.gif    IKernel kernel 
= new DefaultKernel();
InBlock.gif
InBlock.gif
InBlock.gif    MutableConfiguration compNode 
= new MutableConfiguration("component");
InBlock.gif
InBlock.gif    compNode.Attributes[
"id"= "b";
InBlock.gif
InBlock.gif    compNode.Attributes[
"startable"= "true";
InBlock.gif
InBlock.gif    compNode.Attributes[
"startMethod"= "Start";
InBlock.gif
InBlock.gif    compNode.Attributes[
"stopMethod"= "Stop";
InBlock.gif
InBlock.gif    kernel.ConfigurationStore.AddComponentConfiguration(
"b", compNode);
InBlock.gif
InBlock.gif
InBlock.gif    kernel.AddFacility( 
"startable"new StartableFacility() );
InBlock.gif
InBlock.gif    kernel.AddComponent( 
"b"typeof(NoInterfaceStartableComponent) );
InBlock.gif
InBlock.gif    NoInterfaceStartableComponent component 
= kernel["b"as NoInterfaceStartableComponent;
InBlock.gif
InBlock.gif
InBlock.gif    Assert.IsNotNull(component);
InBlock.gif
InBlock.gif    Assert.IsTrue( component.Started );
InBlock.gif
InBlock.gif    Assert.IsFalse( component.Stopped );
InBlock.gif 
InBlock.gif
InBlock.gif    kernel.ReleaseComponent(component);
InBlock.gif
InBlock.gif    Assert.IsTrue( component.Stopped );
InBlock.gif
ExpandedBlockEnd.gif}
对于 IKrnel大家可以自行修改为Castle.Windsor,这样也不失为一种使用Startable Facility的方法。













本文转自lihuijun51CTO博客,原文链接:  http://blog.51cto.com/terrylee/67684 ,如需转载请自行联系原作者
相关文章
|
11天前
|
Java 测试技术 开发者
IoC容器有什么作用?
【4月更文挑战第30天】IoC容器有什么作用?
29 0
|
5天前
|
运维 Kubernetes Devops
构建高效自动化运维体系:DevOps与容器化技术融合实践
【5月更文挑战第6天】随着企业IT架构的复杂化以及快速迭代的市场需求,传统的运维模式已难以满足高效率和高质量的交付标准。本文将探讨如何通过结合DevOps理念和容器化技术来构建一个高效的自动化运维体系,旨在实现持续集成、持续部署和自动化管理,提升系统的可靠性、可维护性和敏捷性。
|
10天前
|
运维 Kubernetes Devops
构建高效稳定的云基础设施:DevOps与容器化技术融合实践
【5月更文挑战第1天】 随着云计算的普及和企业数字化转型的加速,传统的IT运维模式已无法满足快速迭代和高可用性的要求。本文探讨了如何通过DevOps文化和容器化技术的融合来构建一个高效、稳定且可扩展的云基础设施。文章首先回顾了DevOps的核心理念及其对运维工作的影响,随后详细介绍了容器化技术的基本概念、优势以及在现代云环境中的关键作用。接着,文中以一系列真实案例为基础,分析了将DevOps与容器化相结合时所面临的挑战和解决方案,并提出了一套实施框架。最后,文章总结了这种融合实践对提高运维效率、加快产品上市速度和保障系统稳定性的积极影响,同时对未来的技术趋势进行了展望。
|
10天前
|
敏捷开发 运维 测试技术
构建高效自动化运维体系:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】在数字化转型的浪潮中,企业对软件交付速度和质量的要求日益提高。自动化运维作为提升效率、确保稳定性的关键手段,其重要性不言而喻。本文将探讨如何利用容器技术构建一个高效的自动化运维体系,实现从代码提交到产品上线的持续集成(CI)与持续部署(CD)。通过分析现代容器技术与传统虚拟化的差异,阐述容器化带来的轻量化、快速部署及易于管理的优势,并结合实例讲解如何在实际环境中搭建起一套完善的CI/CD流程。
|
10天前
|
Kubernetes Devops Docker
构建高效稳定的云基础设施:DevOps与容器化技术融合实践
【4月更文挑战第30天】 在当今快速迭代和持续交付的软件发展环境中,传统的IT运维模式已不足以满足企业对效率和稳定性的双重需求。本文将深入探讨如何通过整合DevOps理念和容器化技术来构建一个既高效又稳定的云基础设施。文中不仅阐述了DevOps的核心原则、流程自动化的重要性以及容器化技术的基础知识,还提供了一个详细的实施案例,帮助读者理解这两种技术如何协同工作,以支持复杂的应用程序部署和管理。
|
10天前
|
运维 Kubernetes 持续交付
构建高效自动化运维系统:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】 在快速发展的云计算时代,传统的运维模式已无法满足敏捷开发和快速迭代的需求。本文将介绍如何利用容器技术搭建一套高效自动化运维系统,实现软件的持续集成(CI)与持续部署(CD)。文章首先探讨了现代运维面临的挑战,接着详细阐述了容器技术的核心组件和工作原理,最后通过实际案例展示了如何整合这些组件来构建一个可靠、可扩展的自动化运维平台。
|
11天前
|
Java 开发者 容器
IoC容器如何实现依赖注入?
【4月更文挑战第30天】IoC容器如何实现依赖注入?
20 0
|
11天前
|
XML Java 数据格式
如何配置IoC容器?
【4月更文挑战第30天】如何配置IoC容器?
18 0
|
20小时前
|
NoSQL Redis Docker
Mac上轻松几步搞定Docker与Redis安装:从下载安装到容器运行实测全程指南
Mac上轻松几步搞定Docker与Redis安装:从下载安装到容器运行实测全程指南
7 0
|
2天前
|
监控 Kubernetes Docker
【Docker 专栏】Docker 容器内应用的健康检查与自动恢复
【5月更文挑战第9天】本文探讨了Docker容器中应用的健康检查与自动恢复,强调其对应用稳定性和系统性能的重要性。健康检查包括进程、端口和应用特定检查,而自动恢复则涉及重启容器和重新部署。Docker原生及第三方工具(如Kubernetes)提供了相关功能。配置检查需考虑检查频率、应用特性和监控告警。案例分析展示了实际操作,未来发展趋势将趋向更智能和高效的检查恢复机制。
【Docker 专栏】Docker 容器内应用的健康检查与自动恢复