CN106775864A - 一种基于Autofac支持按需加载的服务管理器的实现方法 - Google Patents

Abstract

本发明公开了一种基于Autofac支持按需加载的服务管理器的实现方法，其实现过程为：将任务切分成若干个子任务，并将数据集划分为若干个数据片，根据每一个子任务及其对应的数据分片构建一个可并行执行的独立子任务包，将这些子任务包放入统一的线程池中进行独立的并行执行。本发明的一种基于Autofac支持按需加载的服务管理器的实现方法与现有技术相比，可以充分利用现有系统的资源，提高跑批处理的性能。在并行执行的过程中通过记录子任务执行状态与错误信息，数据执行状态与错误信息来对任务执行过程进行追踪与容错，实用性强，适用范围广泛。

Description

一种基于Autofac支持按需加载的服务管理器的实现方法

技术领域

本发明涉及计算机技术领域，具体地说是一种基于Autofac支持按需加载的服务管理器的实现方法。

背景技术

智能客户端（Smart Client）技术是一种基于互联网（Internet）的富客户端技术。在客户端，采用富客户端（Rich Client）技术，可充分利用客户端机器的本地资源，为用户提供丰富的用户交互体验。与B/S（Browser/Server，浏览器/服务器）应用程序相比，可展现给用户的界面是像安装在本地桌面系统上的GUI（Graphics User Interface，图形用户界面）程序界面，它有很多的复杂界面交互元素如树、菜单、网格等，对用户的友好性和可交互性大大增强，可满足用户界面交互的各种个性化需求，并且可提供本地数据缓存、离线应用等强大功能。而与C/S（Client/Server，客户机/服务器）应用程序对比，智能客户端技术提供客户端程序的自动部署更新，避免了客户端程序维护的各种繁琐和困难。

智能客户端技术提供客户端程序的自动部署更新，避免了客户端程序维护的各种繁琐和困难，也为程序带来了其它方面的复杂性，我们本发明要讨论的服务管理就是其中之一。

面向对象的目标就是设计出高内聚、低耦合的程序。所谓耦合度，是指模块之间相互依赖性大小的度量，耦合度越小，模块的相对独立性越大。耦合关注的是某一模块和其他模块之间的关联性。所谓内聚度,是指模块内各成分之间相互依赖性大小的度量,内聚度越大,模块各成分之间联系越紧密,其功能越强。一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。

耦合关系不仅会出现在软件系统的各模块之间，也会出现在对象与对象之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。软件专家Michael Mattson1996年提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中。

IOC 是 Inversion of Control 的缩写，也叫“控制反转”。它把传统上由程序代码直接操控的对象的调用权交给容器，通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的转移，从程序代码本身转移到了外部容器。IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。

IoC的真正强大之处在于，在运行时而非编译时绑定类间关系。例如，你可以对一个接口进行两种实现：真正的实现和模拟(mock)的实现，而在运行时根据需要去决定真正调用哪一个实现。这尤其当你希望程序在不同场景下表现不同的行为时，这是非常好用的。

Autofac是目前.NET阵营中一款比较流行的解耦框架，以其轻量级、性能高等优点被广泛使用。在使用时发现，IoC配置一旦被加载后，需要遍历配置中每种对象的类型。而对于智能客户端软件，程序文件可能是在软件运行后才自动部署的，如何实现按需加载的服务管理器对于智能客户端程序尤为重要。

基于此，现提供一种基于Autofac支持按需加载的服务管理器的实现方法，基于Autofac框架提供一种按需加载的服务管理器，进而解决智能客户端模式下因程序文件可能后下载而不能使用解耦框架的问题。

发明内容

本发明的技术任务是针对以上不足之处，提供一种高性能、有一定容错能力，且资源得到有效利用的基于Autofac支持按需加载的服务管理器的实现方法。

一种基于Autofac支持按需加载的服务管理器的实现方法，基于Autofac解耦框架、服务管理器，实现适合于智能客户端支持按需加载的服务管理器，其实现过程为：

首先配置服务管理器的服务接口-实现类，使得编程时，不同模块间程序依赖接口，不直接依赖具体的实现类；

然后动态注册服务及解析实例：加载服务管理器配置项，判断服务管理器的服务类型是否已注册；如果已注册，或未注册并进行注册完成后，调用Autofac的Resolve方法获取对象实例。

步骤一中配置内容包括对外提供的服务接口类型、接口实现类的类型及对象实例共享状态定义三部分，同时配置内容还包括可选属性，该可选属性包括配置的名称。

在步骤二中，服务管理器首次加载时，遍历Autofac的配置文件，将所有配置项加载到内存中，且该过程不加载程序类型，只作为字符串项待查询。

判断类型是否已注册是指当外部程序每次调用服务管理器首次获取对象实例时，服务管理器先检测其服务类型是否在Autofac容器内注册。

当服务类型未在Autofac容器内注册时，则服务管理器根据需要，在Autofac容器内注册相关服务类型。

服务管理器根据需要解析的服务类型，从加载的服务管理器配置项中查询是否存在相关名称，如果存在，则继续注册过程，否则抛出异常；

将配置项加载成对象类型，实例化一个全新的Autofac Container对象，然后将类型注册到Container中，最后将原有的Container实例强制更新到新创建的Container中。

本发明的一种基于Autofac支持按需加载的服务管理器的实现方法和现有技术相比，具有以下有益效果：

本发明的一种基于Autofac支持按需加载的服务管理器的实现方法，解决了智能客户端情况下由于服务对象配置存在而程序文件由于未使用到而没有自动部署到本地进而出现报错的问题，同时还能避免初次加载所有类型而出现的性能问题，实用性强，适用范围广泛，易于推广。

附图说明

附图1为本发明的实现流程图。

具体实施方式

下面结合附图及具体实施例对本发明作进一步说明。

如附图1所示，本发明涉及到的一种基于Autofac支持按需加载的服务管理器的实现方法，旨在提供一种基于Autofac解耦框架并且支持延迟加载的服务管理器实现，特别适合于应用于智能客户端程序。

本方法，借助Autofac解耦框架，实现适合于智能客户端支持按需加载的服务管理器。包括如下内容：

编程时，不同模块间程序依赖接口，不直接依赖具体的实现类；运行时，通过服务管理器进行程序实现类的实例化，实现程序的松耦合。

对外提供服务的接口声明与实现可以通过配置文件的方式灵活定义，并且根据实际情况，设定服务的生命周期：单例、每次实例化。

实例化接口的实现类时，考虑智能客户端程序有随时自动更新程序的特点，采用按需加载的方式。

服务的接口类与实现类是通过配置的方式进行管理的，在程序运行期绑定类间关系，而不是编译期绑定类间关系。

具体的，本发明通过服务接口-实现类配置、动态注册服务及解析实例两个步骤实现按需加载的服务管理器。

一、服务接口-实现类配置。

配置主要由对外提供的服务接口类型、接口实现类的类型及对象实例共享状态定义三部分组成，另外还可以定义配置的名称等可选属性，与本发明实现无关不予讨论。

配置的结构如下：

<configSections>

<section name="autofac" type="Autofac.Configuration.SectionHandler,Autofac.Configuration"/>

</configSections>

<autofac defaultAssembly="mscorlib">

<components>

<component type="MsgSenderType1.OnlineMsgSender,TestServiceManager"

instance-scope="SINGLE-INSTANCE" name="online"

service="Core.SPI.IMessageSender,TestServiceManager" />

</components>

每一个Component为一个服务配置项，其结构如下：

type为具体实现类；

service为提供的服务类型；

instance-scope用于定义对象实例的共享状态，常用可选值有Single Instance（单例）、Instance Per Dependency（每次实例化）、Instance Per Lifetime Scope（一个生命周期内单例）；

name：实体类名称（可选的），一个service可以注册多个具体实现类，可通过name获取指定名称的。

二、动态注册服务及解析实例。

具体的步骤如下：

步骤一：服务管理器首次加载时，会遍历Autofac的配置文件，将所有配置项加载到内存中。此步骤不会加载程序类型，只是作为字符串项待查询。

步骤二：当外部程序每次调用服务管理器首次获取对象实例时，服务管理器先检测服务类型是否在Autofac容器内注册，如果已注册，执行步骤五。

如果未注册，执行步骤三。

步骤三：服务管理器根据外部要解析的服务类型，从步骤一加载的配置项中查询，该配置项以列表形式展示。如果存在，则执行步骤四，否则抛出异常。

步骤四：将配置项加载成对象类型，实例化一个全新的Autofac Container对象，然后将类型注册到Container中。然后将原有的Container实例强制更新到新创建的Container中。这样就绕过了Autofac同一Container只能编译一次的问题，达到既能保留原有Container中已注册类型与已缓存的实例对象，又达到了注册新类型的目的。

步骤五：调用Autofac的Resolve方法获取对象实例。

实例：系统提供了国际化语种服务接口，功能A需要调用该接口的方法。

首先定义服务接口-实现类配置，App.Config中autofac配置如下：

<configSections>

<section name="autofac" type="Autofac.Configuration.SectionHandler,Autofac.Configuration"/>

</configSections>

<autofac defaultAssembly="mscorlib">

<components>

<component type="Inspur.GSP.Gsf.I18N.Framework.RemoteClient.LanguageService,Inspur.GSP.Gsf.I18N.Framework.RemoteClient"

instance-scope="SINGLE-INSTANCE" service="Inspur.GSP.Gsf.I18N.Framework.Api.ILanguageService,Inspur.GSP.Gsf.I18N.Framework.Api" />

</components>

然后动态注册及解析，动态注册及解析的主要步骤如下：

步骤一：服务管理器首次加载时，将所有配置项加载到内存中。

/// <summary>

/// 根据autofac配置节读取注册信息

/// </summary>

/// <param name="sectionHandler">配置节内容</param>

private void ReadRegisterConfiguration(SectionHandler sectionHandler)

{

if (sectionHandler != null)

{

foreach (ComponentElement component in sectionHandler.Components)

{

this.components.Add(component);

}

}

}。

步骤二：判断类型是否注册：

/// <summary>

/// 判断服务是否已注册

/// </summary>

/// <param name="serviceType">服务类型</param>

/// <param name="serviceName">服务名（可选）</param>

/// <returns>是否已经注册的标识</returns>

private bool IsRegistered(Type serviceType)

{

return this.LifetimeScope.IsRegistered(serviceType);

}。

步骤三：注册新类型：

private void RegisterComponentWithType(Type serviceType)

{

string assemblyQualifiedName =serviceType.AssemblyQualifiedName.Replace(" ","");

ContainerBuilder builder = new ContainerBuilder();

//遍历所有的Components，将包含此类型的注入进去

List<int> indexs = new List<int>();

for (int i = 0; i < this.components.Count; i++)

{

ComponentElement component = this.components[i];

if (IsComponentMatched(assemblyQualifiedName, component))

{

Type type = LoadType(component.Type);

var registrar = builder.RegisterType(type);

registrar.SingleInstance();

break;

}

}

builder.Update(this.container);

}。

步骤四：调用Autofac的Resolve方法获取对象实例。

/// <summary>

/// Retrieve a service from the context.

/// </summary>

public TService Resolve<TService>()

{

//this.container = builder.Build();

//this.rootLifetimeScope = this.container.BeginLifetimeScope();

return this.LifetimeScope.Resolve<TService>();

}。

通过上面具体实施方式，所述技术领域的技术人员可容易的实现本发明。但是应当理解，本发明并不限于上述的具体实施方式。在公开的实施方式的基础上，所述技术领域的技术人员可任意组合不同的技术特征，从而实现不同的技术方案。

除说明书所述的技术特征外，均为本专业技术人员的已知技术。

Claims (6)

1.一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，基于Autofac解耦框架、服务管理器，实现适合于智能客户端支持按需加载的服务管理器，其实现过程为：

一、首先配置服务管理器的服务接口-实现类，使得编程时，不同模块间程序依赖接口，不直接依赖具体的实现类；

二、然后动态注册服务及解析实例：加载服务管理器配置项，判断服务管理器的服务类型是否已注册；如果已注册，或未注册并进行注册完成后，调用Autofac的Resolve方法获取对象实例。

2.根据权利要求1所述的一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，步骤一中配置内容包括对外提供的服务接口类型、接口实现类的类型及对象实例共享状态定义三部分，同时配置内容还包括可选属性，该可选属性包括配置的名称。

3.根据权利要求1所述的一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，在步骤二中，服务管理器首次加载时，遍历Autofac的配置文件，将所有配置项加载到内存中，且该过程不加载程序类型，只作为字符串项待查询。

4.根据权利要求1或3所述的一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，判断类型是否已注册是指当外部程序每次调用服务管理器首次获取对象实例时，服务管理器先检测其服务类型是否在Autofac容器内注册。

5.根据权利要求1或3所述的一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，当服务类型未在Autofac容器内注册时，则服务管理器根据需要，在Autofac容器内注册相关服务类型。

6.根据权利要求5所述的一种基于Autofac支持按需加载的服务管理器的实现方法，其特征在于，服务管理器根据需要解析的服务类型，从加载的服务管理器配置项中查询是否存在相关名称，如果存在，则继续注册过程，否则抛出异常；

将配置项加载成对象类型，实例化一个全新的Autofac Container对象，然后将类型注册到Container中，最后将原有的Container实例强制更新到新创建的Container中。