使用 DryIoc 替换 Abp 的 DI 框架

一、背景

你说我 castle windsor 库用得好好的，为啥要大费周章的替换成 dryioc 库呢？那就是性能，dryioc 是一款优秀而且轻量级的 di 框架，整个项目代码就两个文件，加起来代码 1 万行左右(ps: 大部分都是注释)。

在各个 ioc 容器的性能评测当中，dryioc 以其优异的性能成为我选择使用他的原因。abp 使用的 castle windsor 在解析复杂对象的时候，速度非常慢，而替换为 dryioc 之后速度可以提升 150% 以上。

【注意】

本文仅对 .net core 相关的库进行更改并测试，.net framework 相关的库并没有进行修改测试。

二、准备

你需要准备如下原料：

1. abp 源码 一份。
2. 测试用的项目一份。
3. visual studio 2017 或者 rider 一份。
4. .net 程序猿一枚。

三、分析

首先，abp 框架的大部分动作基本上都是通过 iiocmanager 这个接口对象进行实现的，它抽象了一层作为一个 di 框架的操作类。它的默认实现是使用的 castle windsor 来进行组件的注入与解析，所以我们只需要将其改为使用 dryioc 的容器其进行操作即可。

其次，在 abp 框架的很多地方都有用到 castle windsor 的 iwindsorcontainer 对象，但一般用到该方法的地方都是注入或者绑定组件注册事件，这些我们都可以重新实现的。

做完了以上的工作仅仅是代表我们的 abp 的所有组件都可以通过 dryioc 来进行注册和解析，不过要和 asp.net core 集成的话，还需要 iserviceprovider 的适配器，针对于适配器 dryioc 也给我们提供了，拿来用即可。

所以，我们基本确定了需要变更的项目主要是 abp 这个核心库，还有 abp.aspnetcore 这个子模块。除了前面两个比较重要的模块之外，还有 abp.entityframeworkcore 相关的库也需要变更，这是因为他们内部都直接使用到了 iwindsorcontainer 对象对容器进行操作的。

四、开撸

4.1 abp 库改造

abp 本身库里面需要改动的地方基本集中在 dependency 文件夹里面，这个文件夹我们之前有讲过，基本所有依赖注入相关的类型与接口都存放在这里面的。

除了依赖注入相关的类型需要更改以外，我们还需要更改各个拦截器注入的地方。因为在之前 abp 如果需要为某个类型注入拦截器的话，是使用到了 iwindsorcontainer 接口所提供的组件注入事件来进行拦截器注入的。

首先我们针对于 abp 库添加 dryioc 库的 nuget 包引用，这里我是安装的 3.1.0-preview-06 版本。

4.1.1 iocmanger 改造

首先看一下 iiocmanager 接口，该接口定义如下：

/// <summary>
/// this interface is used to directly perform dependency injection tasks.
/// </summary>
public interface iiocmanager : iiocregistrar, iiocresolver, idisposable
{
    /// <summary>
    /// reference to the castle windsor container.
    /// </summary>
    iwindsorcontainer ioccontainer { get; }

    /// <summary>
    /// checks whether given type is registered before.
    /// </summary>
    /// <param name="type">type to check</param>
    new bool isregistered(type type);

    /// <summary>
    /// checks whether given type is registered before.
    /// </summary>
    /// <typeparam name="t">type to check</typeparam>
    new bool isregistered<t>();
}

可以看到他定义了一个 iwindsorcontainer 的属性，我们将其改为 icontainer 。基本上做了这一步之后，在 abp 的其他项目会出现一堆错误提示，先不慌，一步一步来。

接着我们转到 iiocmanager 的实现类 iocmanager ，一样的更改 ioccontainer 的类型为 icontainer 之后，我们继续来到其构造函数，可以看到有如下代码：

public iocmanager()
{
    ioccontainer = createcontainer();
    _conventionalregistrars = new list<iconventionaldependencyregistrar>();

    //register self!
    ioccontainer.register(
        component
        .for<iocmanager, iiocmanager, iiocregistrar, iiocresolver>()
        .instance(this)
    );
}

因为我们的 ioccontainer 跟着变更了，这里也不能使用 createcontainer() 方法来创建 dryioc 的容器。其次，在下面注册自己的时候，也是使用到了 iwindsorcontainer 的注册方法，一样的需要进行更改。变更好的构造函数如下：

public iocmanager()
{
    // 这里通过 rules 启用了瞬态对象跟踪，默认是不启动的。
    ioccontainer = new container(rules.default.withtrackingdisposabletransients());
    _conventionalregistrars = new list<iconventionaldependencyregistrar>();

    // 注册自身
    ioccontainer.useinstance(typeof(iocmanager),this);
    ioccontainer.useinstance(typeof(iiocmanager),this);
    ioccontainer.useinstance(typeof(iiocregistrar),this);
    ioccontainer.useinstance(typeof(iiocresolver),this);
}

接着就需要继续看一下报错的方法，另一个需要改的则是注册方法的一个辅助私有方法 applylifestyle，该方法主要作用就是将 abp 定义的生命周期转换为具体 ioc 容器的生命周期常量。而且该方法原来是返回的一个 componentregistration<t> 对象，这个对象是 castle windsor 的一个专属类，所以需要改造一下，变更之后如下：

private static ireuse applylifestyle(dependencylifestyle lifestyle)
{
    switch (lifestyle)
    {
        case dependencylifestyle.transient:
            return reuse.transient;;
        case dependencylifestyle.singleton:
            return reuse.singleton;
        default:
            return reuse.transient;
    }
}

做了这个改动之后，剩下的就是需要针对注册与解析方法进行一些改动了，因为 iocmanger 提供的注册与解析方法也是调用的具体 ioc 容器所提供的方法，而 iwindsorcontainer 提供的，dryioc 的 icontainer 基本上也都有提供 ，只是个别特殊的方法有一些不同而已。

下面是改造完成的部分注册与解析接口(详细的可以查看 github 代码)：

public void register(type type, dependencylifestyle lifestyle = dependencylifestyle.singleton)
{
    ioccontainer.register(type,applylifestyle(lifestyle));
}

// ... 其他接口
public void register(type type, type impl, dependencylifestyle lifestyle = dependencylifestyle.singleton)
{
    if (type == impl)
    {
        // 这里通过 made 参数指定了解析对象时优先解析带有参数的构造函数
        ioccontainer.register(type,impl,applylifestyle(lifestyle),
            made: made.of(factorymethod.constructorwithresolvablearguments));
        registertypeeventhandler?.invoke(this,type,impl);
    }
    else
    {
        ioccontainer.registermany(new[]
            {
                type,
                impl
            },
            impl,
            made: made.of(factorymethod.constructorwithresolvablearguments),
            reuse: applylifestyle(lifestyle));
        
        registertypeeventhandler?.invoke(this,type,impl);
        registertypeeventhandler?.invoke(this,impl,impl);
    }
}

// ... 其他接口

这里需要注意一点的是带参数的解析方法 public t resolve<t>(object argumentsasanonymoustype) ，dryioc 与 castle windsor 不同的是，它能够接收的只能是参数数组，而不能接收一个参数集合的匿名对象。所以我们需要将入参改为 object[] ，当然也因为变更了方法签名，所以我们需要更改 scopediocresolver、iiocresolver、iocresolverextensions 定义里面带参数的解析方法签名。

public t resolve<t>(object[] argumentsasanonymoustype)
{
    return ioccontainer.resolve<t>(argumentsasanonymoustype);
}

其次，还有一个 public t[] resolveall<t>() 内部调用了 ioccontainer.resolveall 方法，而 dryioc 是没有提供这个方法的，但是有一个 resolvemany() 方法是一样的作用。下面是进行更改之后的 resolveall() 方法的所有重载：

///<inheritdoc/>
public t[] resolveall<t>()
{
    return ioccontainer.resolvemany<t>().toarray();
}

///<inheritdoc/>
public t[] resolveall<t>(object[] argumentsasanonymoustype)
{
    return ioccontainer.resolvemany<t>(args:argumentsasanonymoustype).toarray();
}

///<inheritdoc/>
public object[] resolveall(type type)
{
    return ioccontainer.resolvemany(type).toarray();
}

///<inheritdoc/>
public object[] resolveall(type type, object[] argumentsasanonymoustype)
{
    return ioccontainer.resolvemany(type, args:argumentsasanonymoustype).toarray();
}

除了解析方法之外，还有对象释放的方法 release，由于 dryioc 没有提供释放方法，所以这里只能显式地调用对象的 dispose() 方法来进行释放。

public void release(object obj)
{
    if(obj is idisposable disposeobj)
    {
        disposeobj.dispose();
    }
}

做了以上变更之后，还有一个地方在提示错误：

public void registerassemblybyconvention(assembly assembly, conventionalregistrationconfig config)
{
    var context = new conventionalregistrationcontext(assembly, this, config);

    foreach (var registerer in _conventionalregistrars)
    {
        registerer.registerassembly(context);
    }

    if (config.installinstallers)
    {
         // 这里仍然使用了 iwindsorcontainr 的方法
        ioccontainer.install(fromassembly.instance(assembly));
    }
}

看过博主之前更新的 abp 源码分析的同学应该知道，这个 install() 的作用其实很简单，就是直接遍历指定程序集的类型，查找是否有实现了 iwindsorinstaller 接口的对象，如果有则调用其 install() 方法。而在其 install() 方法里面，一般都是通过传入的 iioccontainer 或者是 iiocmanager 对象来进行组件注册的功能。

在这里，我们可以针对 iocmanager 写两个扩展方法 intsall() 和一个 idryiocinstaller 接口用于实现相似的功能。

namespace abp.dependency
{
    public interface idryiocinstaller
    {
        void install(iiocmanager iocmanager);
    }
}

扩展方法：

using system;
using system.linq;
using system.reflection;

namespace abp.dependency
{
    public static class iocmanagerextensions
    {
        public static void install(this iiocmanager iocmanager,idryiocinstaller installer)
        {
            installer.install(iocmanager);
        }

        public static void install(this iiocmanager iocmanager, assembly assembly)
        {
            // 获得指定程序集内部所有的 installer 类型
            var installers = assembly.gettypes().where(type => type.getinterfaces().any(@interface => @interface == typeof(idryiocinstaller)));

            // 遍历类型并通过 activator 进行构造并调用
            foreach (var installer in installers)
            {
                (activator.createinstance(installer) as idryiocinstaller)?.install(iocmanager);
            }
        }
    }
}

现在我们回到最开始报错的地方，将其 install() 方法改为调用我们新的扩展方法。

public void registerassemblybyconvention(assembly assembly, conventionalregistrationconfig config)
{
    var context = new conventionalregistrationcontext(assembly, this, config);

    foreach (var registerer in _conventionalregistrars)
    {
        registerer.registerassembly(context);
    }

    if (config.installinstallers)
    {
        // 调用之前编写的扩展方法
        this.install(assembly);
    }
}

4.1.2 依赖注入辅助接口改造

abp 库本身提供了两个接口 (itransientdependency、isingletondependency ) 来帮助用户快速地注入某个对象，然后通过注册规约结合 iocmanager 提供的 addconventionalregistrar() 方法和 registerassemblybyconvention() 方法能够快速地将某个程序集内部符合规则的类型进行注入。(ps: 这里其实流程很像之前 installer 的做法)

在使用 castle windsor 的时候，abp 本身并不需要做太多的工作，就可以实现上述的功能。而 dryioc 本身是没有提供这些比较高级的特性的，但原理其实并不复杂， 就是扫描整个程序集的所有类型，然后挨个进行判断即可。

在原来的 basicconventionalregistrar 类型内部，对实现了 itransientdependency 、 isingletondependency 、 iinterceptor 接口的类型进行了自动注册。所以我们就有了以下的实现代码：

using system;
using system.linq;
using system.reflection;
using abp.extensions;
using castle.dynamicproxy;

namespace abp.dependency
{
    public class assemblytype
    {
        public type servicetype { get; set; }

        public type impltype { get; set; }
    }
    
    /// <summary>
    /// 本类用于注册实现了 <see cref="itransientdependency"/> 和 <see cref="isingletondependency"/> 接口的类型。
    /// </summary>
    public class basicconventionalregistrar : iconventionaldependencyregistrar
    {
        public void registerassembly(iconventionalregistrationcontext context)
        {
            // 瞬时对象注册
            var waitregistertransient = gettypes<itransientdependency>(context.assembly).tolist();

            foreach (var transienttype in waitregistertransient)
            {
                context.iocmanager.registerifnot(transienttype.servicetype,transienttype.impltype,dependencylifestyle.transient);
            }
            
            // 单例对象注册
            var waitregistersingleton = gettypes<isingletondependency>(context.assembly).tolist();

            foreach (var singletontype in waitregistersingleton)
            {
                context.iocmanager.registerifnot(singletontype.servicetype,singletontype.impltype,dependencylifestyle.singleton);
            }
            
            // castle.dynamicproxy 拦截器注册
            var waitregisterinterceptor = gettypes<iinterceptor>(context.assembly).tolist();

            foreach (var interceptortype in waitregisterinterceptor)
            {
                context.iocmanager.registerifnot(interceptortype.servicetype,interceptortype.impltype,dependencylifestyle.transient);
            }
        }

        private parallelquery<assemblytype> gettypes<tinterface>(assembly assembly)
        {
            type getservicetype(type type)
            {
                var interfaces = type.getinterfaces().where(i => i != typeof(tinterface));

                // 优先匹配去除 i 之后的接口
                var defaultinterface = interfaces.firstordefault(i => type.name.equals(i.name.removeprefix("i")));
                if (defaultinterface != null) return defaultinterface;
                if (interfaces.firstordefault() != null) return interfaces.firstordefault();
                return type;
            }

            return assembly.gettypes()
                .asparallel()
                .where(type => typeof(tinterface).isassignablefrom(type))
                .where(type => type.getinterfaces().any() && !type.isinterface)
                .where(type => !type.isgenerictypedefinition)
                .where(type => !type.isabstract)
                .select(type => new assemblytype
                {
                    servicetype = getservicetype(type),
                    impltype = type
                });
        }
    }
}

在我们实现的新的注册规约当中可以看到，其实最核心的代码在于 gettypes() 方法内部，在其内部进行了比较复杂的判断逻辑，其余的瞬时对象与单例对象的注入，都是直接调用的 iiocmanager 接口所提供的注册方法。

4.1.3 拦截器绑定

因为没有使用 castle windsor ，那么我们拦截器如何使用？又如何与类型进行绑定的呢？

在 dryioc 官方文档已经说明，dryioc 本身的拦截功能也是通过 castle dynamic proxy 来实现的，所以我们只需要编写一个辅助的静态扩展类即可。

using system;
using system.linq;
using castle.dynamicproxy;
using dryioc;
using imtools;

public static class dryiocinterception
{
    static readonly defaultproxybuilder proxybuilder = new defaultproxybuilder();

    public static void intercept(this iregistrator registrator,type servicetype,type interceptortype,type impltype, object servicekey = null)
    {
        // 判断传入的类型是接口还是类型，以便建立代理类
        type proxytype;
        if (servicetype.isinterface())
            proxytype = proxybuilder.createinterfaceproxytypewithtargetinterface(
                servicetype, arraytools.empty<type>(), proxygenerationoptions.default);
        else if (servicetype.isclass())
            proxytype = proxybuilder.createclassproxytypewithtarget(
                servicetype, arraytools.empty<type>(), proxygenerationoptions.default);
        else
            throw new argumentexception(
                $"intercepted service type {servicetype} is not a supported, cause it is nor a class nor an interface");

        // 创建 dryioc 装饰器
        var decoratorsetup = servicekey == null
            ? setup.decoratorwith(usedecorateereuse: true)
            : setup.decoratorwith(r => servicekey.equals(r.servicekey), usedecorateereuse: true);

        // 替换注册原来接口的解析，解析到新的代理类
        registrator.register(servicetype, proxytype,
            made: made.of((type type) => type.getconstructors().singleordefault(c => c.getparameters().length != 0), 
                parameters.of.type<iinterceptor[]>(interceptortype.makearraytype()),
                // 一定要加上这个，不然属性注入无法使用
                propertiesandfields.auto),
            setup: decoratorsetup);
    }
    
    public static void intercept<tservice,timpltype, tinterceptor>(this iregistrator registrator, object servicekey = null) 
        where tinterceptor : class, iinterceptor
    {
        intercept(registrator,typeof(tservice),typeof(tinterceptor),typeof(timpltype),servicekey);
    }
}

这个扩展类的用法，在后面就有体现。

4.1.4 拦截器注册器绑定事件

最开始 abp 拦截器是在什么时候与具体类型绑定的呢？其实就是在 castle windsor 注入组件的时候，各个拦截器注册器都会监听这个组件注入事件。当事件被触发的时候，abp 各个拦截器注册器都会执行一系列的判断来确保当前类型应该绑定哪一个拦截器。

abp 自带的拦截器一共有 5 种：工作单元拦截器、参数验证拦截器、授权拦截器、审计日志拦截器、实体历史拦截器。这五种拦截器都是在 abpbootstrapper 执行创建方法的时候会被调用，调用的时候会监听组件注册事件。

现在的问题是，我们已经没有使用 castle windsor 也就没有办法使用 iwindsorcontainer 来监听组件注册事件。而 dryioc 本身也是没有提供这种注入事件的，所以这里我们就只有抽象到 iocmanager 类型当中，当 iocmanager 的几个注册方法被调用的时候，显式触发一个事件通知这些拦截器注册器对象。

首先我们来到 iiocmanager 接口，为其添加一个公开的委托属性，该委托的定义也在下面给出来了。

委托定义：

using system;

namespace abp.dependency
{
    public delegate void registertypeeventhandler(iiocmanager iocmanager, type registertype,type implementationtype);
}

iiocmanager 接口处新增的属性：

using system;
using dryioc;

namespace abp.dependency
{
    /// <summary>
    /// 依赖注入容器管理器,
    /// 本接口用于执行注入操作
    /// </summary>
    public interface iiocmanager : iiocregistrar, iiocresolver, idisposable
    {
        icontainer ioccontainer { get; }

        new bool isregistered(type type);

        new bool isregistered<t>();

        event registertypeeventhandler registertypeeventhandler;
    }
}

之后呢，我们在 iocmanager 的 register() 注册方法内部都显式地触发这个事件。

public void register(type type, dependencylifestyle lifestyle = dependencylifestyle.singleton)
{
    ioccontainer.register(type,applylifestyle(lifestyle),
        made: made.of(factorymethod.constructorwithresolvablearguments));
    registertypeeventhandler?.invoke(this,type,type);
}

就如同这样，实现的效果也是每当有组件注册的时候，都会触发该事件。而各个注册器内部的 initialize() 方法都传入了一个 iiocmanager 对象，所以我们只需要将原有的监听事件改为绑定我们自己定义的事件即可。

下面以工作单元的拦截器注册器为例：

using system.linq;
using system.reflection;
using abp.dependency;
using castle.core;
using castle.microkernel;

namespace abp.domain.uow
{
    /// <summary>
    /// this class is used to register interceptor for needed classes for unit of work mechanism.
    /// </summary>
    internal static class unitofworkregistrar
    {
        /// <summary>
        /// initializes the registerer.
        /// </summary>
        /// <param name="iocmanager">ioc manager</param>
        public static void initialize(iiocmanager iocmanager)
        {
            iocmanager.registertypeeventhandler += (manager, type, implementationtype) =>
            {
                var impltype = implementationtype.gettypeinfo();

                handletypeswithunitofworkattribute(impltype,manager);
                handleconventionalunitofworktypes(iocmanager, impltype);
            };
        }

        private static void handletypeswithunitofworkattribute(typeinfo implementationtype,iiocmanager iocmanager)
        {
            if (isunitofworktype(implementationtype) || anymethodhasunitofwork(implementationtype))
            {
                // 使用的是上面写的扩展方法
                iocmanager.ioccontainer.intercept(implementationtype,typeof(unitofworkinterceptor));
            }
        }

        private static void handleconventionalunitofworktypes(iiocmanager iocmanager, typeinfo implementationtype)
        {
            if (!iocmanager.isregistered<iunitofworkdefaultoptions>())
            {
                return;
            }

            var uowoptions = iocmanager.resolve<iunitofworkdefaultoptions>();

            if (uowoptions.isconventionaluowclass(implementationtype.astype()))
            {
                // 使用的是上面写的扩展方法
                iocmanager.ioccontainer.intercept(implementationtype,typeof(unitofworkinterceptor));
            }
        }

        private static bool isunitofworktype(typeinfo implementationtype)
        {
            return unitofworkhelper.hasunitofworkattribute(implementationtype);
        }

        private static bool anymethodhasunitofwork(typeinfo implementationtype)
        {
            return implementationtype
                .getmethods(bindingflags.instance | bindingflags.public | bindingflags.nonpublic)
                .any(unitofworkhelper.hasunitofworkattribute);
        }
    }
}

按照上面这种步骤，完成剩余拦截器注册器的更改。

4.1.5 收尾工作

如果上述操作都已经完成了的话，那么基本上只剩下 abpbootstrapper 类型与 abpkernelmodule 几处细小的错误了。

首先我们看一下 abpbootstrapper 还提示哪些错误，然后我们进行更改。

// 第一处
public virtual void initialize()
{
    resolvelogger();

    try
    {
        registerbootstrapper();
        
        // iocmanager.ioccontainer.install(new abpcoreinstaller());
        // 此处使用的仍然是 iwindsorcontainer 的 install 方法，改为最新的
        iocmanager.install(new abpcoreinstaller());

        iocmanager.resolve<abppluginmanager>().pluginsources.addrange(pluginsources);
        iocmanager.resolve<abpstartupconfiguration>().initialize();

        _modulemanager = iocmanager.resolve<abpmodulemanager>();
        _modulemanager.initialize(startupmodule);
        _modulemanager.startmodules();
    }
    catch (exception ex)
    {
        _logger.fatal(ex.tostring(), ex);
        throw;
    }
}

上面仍然报错，我们继续来到 abpcoreinstaller 将其接口由 iwindsorinstaller 改为 idryiocinstaller 并重新实现接口的方法。

using abp.application.features;
using abp.auditing;
using abp.backgroundjobs;
using abp.configuration.startup;
using abp.domain.uow;
using abp.entityhistory;
using abp.localization;
using abp.modules;
using abp.notifications;
using abp.plugins;
using abp.reflection;
using abp.resources.embedded;
using abp.runtime.caching.configuration;
using dryioc;

namespace abp.dependency.installers
{
    /// <summary>
    /// abp 框架核心类安装器
    /// 本类用于注册 abp 框架当中核心组件
    /// </summary>
    internal class abpcoreinstaller : idryiocinstaller
    {
        public void install(iiocmanager iocmanager)
        {
            iocmanager.ioccontainer.registermany(new[] {typeof(iunitofworkdefaultoptions), typeof(unitofworkdefaultoptions)}, typeof(unitofworkdefaultoptions), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(inavigationconfiguration), typeof(navigationconfiguration)}, typeof(navigationconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ilocalizationconfiguration), typeof(localizationconfiguration)}, typeof(localizationconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iauthorizationconfiguration), typeof(authorizationconfiguration)}, typeof(authorizationconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ivalidationconfiguration), typeof(validationconfiguration)}, typeof(validationconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ifeatureconfiguration), typeof(featureconfiguration)}, typeof(featureconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(isettingsconfiguration), typeof(settingsconfiguration)}, typeof(settingsconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(imoduleconfigurations), typeof(moduleconfigurations)}, typeof(moduleconfigurations), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ieventbusconfiguration), typeof(eventbusconfiguration)}, typeof(eventbusconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(imultitenancyconfig), typeof(multitenancyconfig)}, typeof(multitenancyconfig), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(icachingconfiguration), typeof(cachingconfiguration)}, typeof(cachingconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iauditingconfiguration), typeof(auditingconfiguration)}, typeof(auditingconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ibackgroundjobconfiguration), typeof(backgroundjobconfiguration)}, typeof(backgroundjobconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(inotificationconfiguration), typeof(notificationconfiguration)}, typeof(notificationconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iembeddedresourcesconfiguration), typeof(embeddedresourcesconfiguration)}, typeof(embeddedresourcesconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iabpstartupconfiguration), typeof(abpstartupconfiguration)}, typeof(abpstartupconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ientityhistoryconfiguration), typeof(entityhistoryconfiguration)}, typeof(entityhistoryconfiguration), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(itypefinder), typeof(typefinder)}, typeof(typefinder), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iabppluginmanager), typeof(abppluginmanager)}, typeof(abppluginmanager), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iabpmodulemanager), typeof(abpmodulemanager)}, typeof(abpmodulemanager), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(iassemblyfinder), typeof(abpassemblyfinder)}, typeof(abpassemblyfinder), reuse.singleton);
            iocmanager.ioccontainer.registermany(new[] {typeof(ilocalizationmanager), typeof(localizationmanager)}, typeof(localizationmanager), reuse.singleton);
        }
    }
}

而 abpbootstrapper 类型还有一处问题一样是使用了 iwindsorcontainer 提供的方法，这里改为 dryioc 提供的方法即可。

private void registerbootstrapper()
{
    if (!iocmanager.isregistered<abpbootstrapper>())
    {
        //                iocmanager.ioccontainer.register(
        //                    component.for<abpbootstrapper>().instance(this)
        //                    );
        iocmanager.ioccontainer.useinstance(this);
    }
}

第二个问题则是 abpkernelmodule 当中的报错，其实与上一个类型的错误一样，第一个是调用了之前的 install 的方法，并且 intsaller 也不是继承自 idryiocinstaller，另一个问题则是使用了 iwindsorcontainer 里面的注册方法。

public override void initialize()
{
    foreach (var replaceaction in ((abpstartupconfiguration)configuration).servicereplaceactions.values)
    {
        replaceaction();
    }

    //            iocmanager.ioccontainer.install(new eventbusinstaller(iocmanager));
    iocmanager.install(new eventbusinstaller(iocmanager));

    iocmanager.register(typeof(ionlineclientmanager<>), typeof(onlineclientmanager<>), dependencylifestyle.singleton);

    iocmanager.registerassemblybyconvention(typeof(abpkernelmodule).getassembly(),
                                            new conventionalregistrationconfig
                                            {
                                                installinstallers = false
                                            });
}

eventbusinstaller 的变更：

using system.reflection;
using abp.configuration.startup;
using abp.dependency;
using abp.events.bus.factories;
using abp.events.bus.handlers;
using castle.microkernel;
using castle.microkernel.registration;
using castle.microkernel.subsystems.configuration;
using castle.windsor;
using dryioc;

namespace abp.events.bus
{
    /// <summary>
    /// installs event bus system and registers all handlers automatically.
    /// </summary>
    internal class eventbusinstaller : idryiocinstaller
    {
        private readonly iiocresolver _iocresolver;
        private readonly ieventbusconfiguration _eventbusconfiguration;
        private ieventbus _eventbus;

        public eventbusinstaller(iiocresolver iocresolver)
        {
            _iocresolver = iocresolver;
            _eventbusconfiguration = iocresolver.resolve<ieventbusconfiguration>();
        }
        
        public void install(iiocmanager iocmanager)
        {
            if (_eventbusconfiguration.usedefaulteventbus)
            {
                iocmanager.ioccontainer.useinstance<ieventbus>(eventbus.default);
            }
            else
            {
                iocmanager.ioccontainer.register<ieventbus,eventbus>(reuse.singleton);
            }

            _eventbus = iocmanager.resolve<ieventbus>();
            iocmanager.registertypeeventhandler += (manager, type, implementationtype) =>
            {
                if (!typeof(ieventhandler).gettypeinfo().isassignablefrom(implementationtype))
                {
                    return;
                }

                var interfaces = implementationtype.gettypeinfo().getinterfaces();
                foreach (var @interface in interfaces)
                {
                    if (!typeof(ieventhandler).gettypeinfo().isassignablefrom(@interface))
                    {
                        continue;
                    }

                    var genericargs = @interface.getgenericarguments();
                    if (genericargs.length == 1)
                    {
                        _eventbus.register(genericargs[0], new iochandlerfactory(_iocresolver, implementationtype));
                    }
                }
            };
        }
    }
}

另外一处的变更如下：

private void registermissingcomponents()
{
    if (!iocmanager.isregistered<iguidgenerator>())
    {
        //                iocmanager.ioccontainer.register(
        //                    component
        //                        .for<iguidgenerator, sequentialguidgenerator>()
        //                        .instance(sequentialguidgenerator.instance)
        //                );
        iocmanager.ioccontainer.useinstance<iguidgenerator>(sequentialguidgenerator.instance);
        iocmanager.ioccontainer.useinstance<sequentialguidgenerator>(sequentialguidgenerator.instance);
    }

    iocmanager.registerifnot<iunitofwork, nullunitofwork>(dependencylifestyle.transient);
    iocmanager.registerifnot<iauditingstore, simplelogauditingstore>(dependencylifestyle.singleton);
    iocmanager.registerifnot<ipermissionchecker, nullpermissionchecker>(dependencylifestyle.singleton);
    iocmanager.registerifnot<irealtimenotifier, nullrealtimenotifier>(dependencylifestyle.singleton);
    iocmanager.registerifnot<inotificationstore, nullnotificationstore>(dependencylifestyle.singleton);
    iocmanager.registerifnot<iunitofworkfilterexecuter, nullunitofworkfilterexecuter>(dependencylifestyle.singleton);
    iocmanager.registerifnot<iclientinfoprovider, nullclientinfoprovider>(dependencylifestyle.singleton);
    iocmanager.registerifnot<itenantstore, nulltenantstore>(dependencylifestyle.singleton);
    iocmanager.registerifnot<itenantresolvercache, nulltenantresolvercache>(dependencylifestyle.singleton);
    iocmanager.registerifnot<ientityhistorystore, nullentityhistorystore>(dependencylifestyle.singleton);

    if (configuration.backgroundjobs.isjobexecutionenabled)
    {
        iocmanager.registerifnot<ibackgroundjobstore, inmemorybackgroundjobstore>(dependencylifestyle.singleton);
    }
    else
    {
        iocmanager.registerifnot<ibackgroundjobstore, nullbackgroundjobstore>(dependencylifestyle.singleton);
    }
}

4.1.6 测试

做完以上变更之后，新建一个控制台程序，引用这个 abp 库项目，然后键入以下代码进行测试即可。

using system;
using abp;
using abp.modules;
using abp.runtime.session;

namespace consoleapp
{
    class program
    {
        static void main(string[] args)
        {
            // abp 框架测试
            using (var bootstarp = abpbootstrapper.create<startupmodule>())
            {
                bootstarp.initialize();
                
                // 解析 iabpsession 看是否正常地进行了注入
                var session = bootstarp.iocmanager.resolve<iabpsession>();

                if (session != null && session is claimsabpsession claimssession)
                {
                    console.writeline("当前 session 已经成功被注入为 claimabpsession");
                }
            }

            console.readline();
        }
    }

    [dependson(typeof(abpkernelmodule))]
    public class startupmodule : abpmodule
    {
        
    }
}

4.2 efcore 库与相关库改造

针对 abp 库进行测试之后，基本上我们 abp 现在所有组件都是通过 dryioc 来进行注册与解析的了。不过仅仅针对 abp 做这些更改其实是不够的，除了 abp 核心库之外，我们最常用的就是数据库操作了。因为在 abp.entityframeworkcore 库 和 abp.entityframework.common 的内部也有部分代码在之前是直接通过 iwindsorcontainer 进行注册与解析操作的，所以我们也得继续改报错的地方。

4.2.1 仓储类注册

在 abp.entityframework.common 库的 efgenericrepositoryregistrar 类型内部，有使用到 iwindsorcontainer 的组件注册方法，用于注入 irepository<,> 泛型仓储。下面代码展示的更改后的结果：

private void registerfordbcontext(
    type dbcontexttype, 
    iiocmanager iocmanager,
    type repositoryinterface,
    type repositoryinterfacewithprimarykey,
    type repositoryimplementation,
    type repositoryimplementationwithprimarykey)
{
    foreach (var entitytypeinfo in _dbcontextentityfinder.getentitytypeinfos(dbcontexttype))
    {
        var primarykeytype = entityhelper.getprimarykeytype(entitytypeinfo.entitytype);
        if (primarykeytype == typeof(int))
        {
            var genericrepositorytype = repositoryinterface.makegenerictype(entitytypeinfo.entitytype);
            if (!iocmanager.isregistered(genericrepositorytype))
            {
                var impltype = repositoryimplementation.getgenericarguments().length == 1
                    ? repositoryimplementation.makegenerictype(entitytypeinfo.entitytype)
                    : repositoryimplementation.makegenerictype(entitytypeinfo.declaringtype,
                        entitytypeinfo.entitytype);

//                        iocmanager.ioccontainer.register(
//                            component
//                                .for(genericrepositorytype)
//                                .implementedby(impltype)
//                                .named(guid.newguid().tostring("n"))
//                                .lifestyletransient()
//                        );
                iocmanager.ioccontainer.register(genericrepositorytype,impltype,reuse.transient);
            }
        }

        var genericrepositorytypewithprimarykey = repositoryinterfacewithprimarykey.makegenerictype(entitytypeinfo.entitytype,primarykeytype);
        if (!iocmanager.isregistered(genericrepositorytypewithprimarykey))
        {
            var impltype = repositoryimplementationwithprimarykey.getgenericarguments().length == 2
                ? repositoryimplementationwithprimarykey.makegenerictype(entitytypeinfo.entitytype, primarykeytype)
                : repositoryimplementationwithprimarykey.makegenerictype(entitytypeinfo.declaringtype, entitytypeinfo.entitytype, primarykeytype);

//                    iocmanager.ioccontainer.register(
//                        component
//                            .for(genericrepositorytypewithprimarykey)
//                            .implementedby(impltype)
//                            .named(guid.newguid().tostring("n"))
//                            .lifestyletransient()
//                    );
            iocmanager.ioccontainer.register(genericrepositorytypewithprimarykey,impltype,reuse.transient);
        }
    }
}

按照以上方法更改之后，abp.entityframework.common 应该可以正常地进行编译了。

4.2.2 dbcontext 配置类更改

在 abpefcoreconfiguration 类型当中，也有使用到 iwindsorcontainer 接口的地方，进行如下变更即可：

using system;
using abp.dependency;
using castle.microkernel.registration;
using dryioc;
using microsoft.entityframeworkcore;

namespace abp.entityframeworkcore.configuration
{
    public class abpefcoreconfiguration : iabpefcoreconfiguration
    {
        private readonly iiocmanager _iocmanager;

        public abpefcoreconfiguration(iiocmanager iocmanager)
        {
            _iocmanager = iocmanager;
        }

        public void adddbcontext<tdbcontext>(action<abpdbcontextconfiguration<tdbcontext>> action) 
            where tdbcontext : dbcontext
        {
//            _iocmanager.ioccontainer.register(
//                component.for<iabpdbcontextconfigurer<tdbcontext>>().instance(
//                    new abpdbcontextconfigureraction<tdbcontext>(action)
//                ).isdefault()
//            );
            _iocmanager.ioccontainer.useinstance<iabpdbcontextconfigurer<tdbcontext>>(new abpdbcontextconfigureraction<tdbcontext>(action));
        }
    }
}

4.2.3 efcore 库模块变更

该错误在 abpentityframeworkcoremodule 模块的 initialize() 方法里面，一样的是因为使用了 iwndsorcontainer 的注册方法导致的。

public override void initialize()
{
    iocmanager.registerassemblybyconvention(typeof(abpentityframeworkcoremodule).assembly);

//            iocmanager.ioccontainer.register(
//                component.for(typeof(idbcontextprovider<>))
//                    .implementedby(typeof(unitofworkdbcontextprovider<>))
//                    .lifestyletransient()
//                );
    iocmanager.ioccontainer.register(typeof(idbcontextprovider<>),typeof(unitofworkdbcontextprovider<>),reuse.transient);

    registergenericrepositoriesandmatchdbcontexes();
}

而另一处错误则是在 registergenericrepositoriesandmatchdbcontexes() 方法内部：

private void registergenericrepositoriesandmatchdbcontexes()
{
    // ... 其他的代码
    using (iscopediocresolver scope = iocmanager.createscope())
    {
        foreach (var dbcontexttype in dbcontexttypes)
        {
            logger.debug("registering dbcontext: " + dbcontexttype.assemblyqualifiedname);

            scope.resolve<iefgenericrepositoryregistrar>().registerfordbcontext(dbcontexttype, iocmanager, efcoreautorepositorytypes.default);

//                    iocmanager.ioccontainer.register(
//                        component.for<isecondaryormregistrar>()
//                            .named(guid.newguid().tostring("n"))
//                            .instance(new efcorebasedsecondaryormregistrar(dbcontexttype, scope.resolve<idbcontextentityfinder>()))
//                            .lifestyletransient()
//                    );
            iocmanager.ioccontainer.useinstance<isecondaryormregistrar>(new efcorebasedsecondaryormregistrar(dbcontexttype,
                scope.resolve<idbcontextentityfinder>()));
        }

        scope.resolve<idbcontexttypematcher>().populate(dbcontexttypes);
    }
}

4.2.4 dbcontext 解析器变更

这个解析器的主要问题则与前面的不一样，这里报错是因为在构造 dbcontext 的时候需要传入构造参数。根据我们之前的改动，现在 resolve() 方法传入的是一个 object[] 数组，而不是原来的 object 对象，所以这里需要进行一些细微的改动。

using abp.dependency;
using abp.entityframework;
using abp.entityframeworkcore.configuration;
using microsoft.entityframeworkcore;
using system;
using system.data.common;
using system.reflection;
using jetbrains.annotations;
using microsoft.entityframeworkcore.metadata.internal;
using system.linq;

namespace abp.entityframeworkcore
{
    public class defaultdbcontextresolver : idbcontextresolver, itransientdependency
    {
        // ... 其他代码
    
        public tdbcontext resolve<tdbcontext>(string connectionstring, dbconnection existingconnection)
            where tdbcontext : dbcontext
        {
        
            // ... 其他代码

            try
            {
                if (isabstractdbcontext)
                {
//                    return (tdbcontext) _iocresolver.resolve(concretetype, new
//                    {
//                        options = createoptionsfortype(concretetype, connectionstring, existingconnection)
//                    });
                    
                    return (tdbcontext) _iocresolver.resolve(concretetype, new object[]
                    {
                        createoptionsfortype(concretetype, connectionstring, existingconnection)
                    });
                }

//                return _iocresolver.resolve<tdbcontext>(new
//                {
//                    options = createoptions<tdbcontext>(connectionstring, existingconnection)
//                });

                return _iocresolver.resolve<tdbcontext>(new object[]
                {
                    createoptions<tdbcontext>(connectionstring, existingconnection)
                });
            }
            catch (castle.microkernel.resolvers.dependencyresolverexception ex)
            {
                // ... 其他代码
            }
            
            // ... 其他代码
        }

        // ... 其他代码
    }
}

至此，针对于 efcore 相关的库改造就已经成功完成了。

4.3 asp .net core 相关改造

到目前，我们已经针对 abp 的核心库和 ef core 库都进行了一些不算大的改动，现在就只剩 abp.aspnetcore 库了。因为 .net core 自己使用了一套 di 框架。而我们在之前的源码分析也有讲到过，通过更改 startup 类的 configureservice() 方法的返回值为 iserviceprovider，就可以将原来内部的 di 框架替换为其他的 di 框架。

在原来 abp.aspnetcore 库的 abpservicecollectionextensions 扩展类当中可以看到以下代码：

public static iserviceprovider addabp<tstartupmodule>(this iservicecollection services, [canbenull] action<abpbootstrapperoptions> optionsaction = null)
    where tstartupmodule : abpmodule
{
    var abpbootstrapper = addabpbootstrapper<tstartupmodule>(services, optionsaction);

    configureaspnetcore(services, abpbootstrapper.iocmanager);

    return windsorregistrationhelper.createserviceprovider(abpbootstrapper.iocmanager.ioccontainer, services);
}

这里我们可以看到，abp 通过 windsorregistrationhelper 类创建并返回了一个 iserviceprovider 对象。那么 dryioc 是否也为我们提供了这样的扩展方法呢？答案是有的，dryioc 通过 dryioc.microsoft.dependencyinjection 给我们提供了一个适配器，该适配器可以基于 dryioc 创建一个 iserviceprovier 来替换掉默认的 di 框架。

首先我们为 abp.aspnetcore 库添加 dryioc.microsoft.dependencyinjection 的 nuget 包，然后编辑上述方法：

public static iserviceprovider addabp<tstartupmodule>(this iservicecollection services, [canbenull] action<abpbootstrapperoptions> optionsaction = null)
    where tstartupmodule : abpmodule
{
    var abpbootstrapper = addabpbootstrapper<tstartupmodule>(services, optionsaction);

    configureaspnetcore(services, abpbootstrapper.iocmanager);

    var newcontainer = new container(rules =>
            rules.withautoconcretetyperesolution())
        .withdependencyinjectionadapter(services);
    
    abpbootstrapper.iocmanager.initializeinternalcontainer(newcontainer);
    
    return abpbootstrapper.iocmanager.ioccontainer.buildserviceprovider();
}

4.3.1 视图组件与其他组件的自动注册

除了更改上述问题之外，在 abp.aspnetcore 库还有一个注册器 abpaspnetcoreconventionalregistrar，在里面也使用了 iwindsorcontainer 接口的注册方法，此处也需要进行更改。

using system.linq;
using abp.dependency;
using microsoft.aspnetcore.mvc;

namespace abp.aspnetcore
{
    public class abpaspnetcoreconventionalregistrar : iconventionaldependencyregistrar
    {
        public void registerassembly(iconventionalregistrationcontext context)
        {
            //viewcomponents
            var types = context.assembly.gettypes()
                .asparallel()
                .where(type => typeof(viewcomponent).isassignablefrom(type))
                .where(type => !type.isgenerictypedefinition)
                .where(type => !type.isabstract)
                .assequential();

            foreach (var type in types)
            {
                context.iocmanager.register(type);
            }
        }
    }
}

完成以上操作之后，我们新建 4 个项目，分别是 aspnetcoreapp(web 项目) 、 aspnetcoreapp.core(库项目) 、aspnetcore.application(库项目) 、 aspnetcoreapp.entityframeworkcore(库项目) ，并且配置好各自的依赖关系。

4.3.2 iserviceprovider 适配器

首先我们更改 aspnetcoreapp 下面的 configureservice() 方法与 configure() 方法如下：

using system;
using abp.aspnetcore;
using microsoft.aspnetcore.builder;
using microsoft.aspnetcore.hosting;
using microsoft.extensions.dependencyinjection;

namespace aspnetcoreapp
{
    public class startup
    {
        public iserviceprovider configureservices(iservicecollection services)
        {
            services.addmvc();
            return services.addabp<aspnetcoreappmodule>();
        }

        // this method gets called by the runtime. use this method to configure the http request pipeline.
        public void configure(iapplicationbuilder app, ihostingenvironment env)
        {
            app.usemvc();
            app.useabp(op=>op.usecastleloggerfactory = false);
        }
    }
}

不出意外的话，会抛出以下异常信息：

上述异常的意思是说无法解析 microsoft.aspnetcore.hosting.internal.webhostoptions 对象，这说明我们的 dryioc 容器并没有将 mvc 服务初始化注入的对象获取到。

我们在 addabp<tstartupmodule>() 方法内打一个断点，看一下在 configureaspnetcore() 方法内部注入的对象是否放在 icontainer 里面，结果发现并没有。

所以之后呢，我经过测试，只有 new 一个新的 container 对象，然后对其调用 withdependencyinjectionadapter() 方法才会正常的获取到注入的 mvc 组件。

效果：

那么就需要将 iocmanager 内部的 ioccontainer 赋值为这里创建的 newcontainer 对象，而 iiocmanager 接口所定义的 ioccontainer 属性是只读的。所以这里我为 iiocmanager 接口新增了一个 initializeinternalcontainer() 方法用于初始化 ioccontainer 属性。

public interface iiocmanager : iiocregistrar, iiocresolver, idisposable
{

    // ... 其他代码
    
    /// <summary>
    /// 类型注册事件
    /// </summary>
    event registertypeeventhandler registertypeeventhandler;

    /// <summary>
    /// 初始化 iocmanager 内部的容器
    /// </summary>
    void initializeinternalcontainer(icontainer dryioccontainer);
}

iocmanager 需要实现该方法，并且将其构造器内的相关注册方法移动到 initializeinternalcontainer() 内部。

public class iocmanager : iiocmanager
{
    // ... 其他代码

    public iocmanager()
    {
        _conventionalregistrars = new list<iconventionaldependencyregistrar>();
    }
    
    public void initializeinternalcontainer(icontainer dryioccontainer)
    {
        ioccontainer = dryioccontainer;
        
        //register self!
        ioccontainer.useinstance(typeof(iocmanager),this);
        ioccontainer.useinstance(typeof(iiocmanager),this);
        ioccontainer.useinstance(typeof(iiocregistrar),this);
        ioccontainer.useinstance(typeof(iiocresolver),this);
    }
    
    // ... 其他代码
}

之后再回到最开始的地方，我们最终 addabp<tstartupmodule>() 方法的内部实现是下面这个样子的：

public static iserviceprovider addabp<tstartupmodule>(this iservicecollection services, [canbenull] action<abpbootstrapperoptions> optionsaction = null)
    where tstartupmodule : abpmodule
{
    var abpbootstrapper = addabpbootstrapper<tstartupmodule>(services, optionsaction);

    configureaspnetcore(services, abpbootstrapper.iocmanager);

    var newcontainer = new container().withdependencyinjectionadapter(services);
    abpbootstrapper.iocmanager.initializeinternalcontainer(newcontainer);
    
    return abpbootstrapper.iocmanager.ioccontainer.buildserviceprovider();
}

运行 aspnetcoreapp 项目，我们可以看到正常运行了。

五、存在的问题

5.1 applicationservice 属性注入失效

在示例项目当中，我在 aspnetcoreapp.application 库当中建立了一个 testapplicationservice 服务，该服务用有一个 getjson() 方法。

在其内部，我调用了父类提供的 abpsession 属性，按照正常的情况下，该属性的实现应该是 claimsabpsession 类型，不过通过测试之后我得到了以下结果：

可以看到，它填充的是默认的空实现，造成这个问题的原因是，dryioc 本身在注册对象的时候，需要显式提供属性注入的选项，否则默认是不启用属性注入的。

鉴于此，我们为 iiocregistrar 与 iocmanager 内所提供的 register() 方法增加一个 isautoinjectproperty 字段，用于判断是否在注册的使用启用属性注入。

public interface iiocregistrar
{
    /// <summary>
    /// registers a type as self registration.
    /// </summary>
    /// <typeparam name="t">type of the class</typeparam>
    /// <param name="lifestyle">lifestyle of the objects of this type</param>
    void register<t>(dependencylifestyle lifestyle = dependencylifestyle.singleton,bool isautoinjectproperty = false)
        where t : class;

    /// <summary>
    /// registers a type as self registration.
    /// </summary>
    /// <param name="type">type of the class</param>
    /// <param name="lifestyle">lifestyle of the objects of this type</param>
    void register(type type, dependencylifestyle lifestyle = dependencylifestyle.singleton,bool isautoinjectproperty = false);

    /// <summary>
    /// registers a type with it's implementation.
    /// </summary>
    /// <typeparam name="ttype">registering type</typeparam>
    /// <typeparam name="timpl">the type that implements <see cref="ttype"/></typeparam>
    /// <param name="lifestyle">lifestyle of the objects of this type</param>
    void register<ttype, timpl>(dependencylifestyle lifestyle = dependencylifestyle.singleton,bool isautoinjectproperty = false)
        where ttype : class
        where timpl : class, ttype;

    /// <summary>
    /// registers a type with it's implementation.
    /// </summary>
    /// <param name="type">type of the class</param>
    /// <param name="impl">the type that implements <paramref name="type"/></param>
    /// <param name="lifestyle">lifestyle of the objects of this type</param>
    void register(type type, type impl, dependencylifestyle lifestyle = dependencylifestyle.singleton,bool isautoinjectproperty = false);
}

而具体实现则需要使用 isautoinjectproperty 来判断是否需要属性注入功能，下面随便以一个 register() 方法为例。

public void register(type type, dependencylifestyle lifestyle = dependencylifestyle.singleton,bool isautoinjectproperty = false)
{
    ioccontainer.register(type,
        applylifestyle(lifestyle),
        made: made.of(factorymethod.constructorwithresolvablearguments,
            propertiesandfields: isautoinjectproperty
                ? propertiesandfields.auto
                : null));
    registertypeeventhandler?.invoke(this,
        type,
        type);
}

写好之后，我们再回到 basicconventionalregistrar 注册器当中，因为应用服务类型个都是瞬时对象，并且应用服务都会继承 iapplicationservice 接口。所以我们加一个判断，如果是应用服务的话，则在注册的时候，允许进行属性注入。

public class basicconventionalregistrar : iconventionaldependencyregistrar
{
    // ... 其他代码

    public void registerassembly(iconventionalregistrationcontext context)
    {
        // 瞬时对象注册
        var waitregistertransient = gettypes<itransientdependency>(context.assembly).tolist();

        foreach (var transienttype in waitregistertransient)
        {
            if (typeof(iapplicationservice).isassignablefrom(transienttype.impltype))
            {
                context.iocmanager.register(transienttype.servicetype,transienttype.impltype,dependencylifestyle.transient,true);
                continue;
            }
            
            context.iocmanager.registerifnot(transienttype.servicetype,transienttype.impltype,dependencylifestyle.transient);
        }
        
        // ... 其他代码
    }
}

进行了上述更改之后，再次调用接口进行测试可以看到属性已经被正常地注入了。

ps:

这里一定要注意 aspnetcoreapp.application 库里面的 aspnetcoreappappicationmodule 模块一定要在 initialize() 方法调用 iocmanager.registerassemblybyconvention(typeof(aspnetcoreappapplicationmodule).assembly); 否则应用服务不会被注入到 ioc 容器当中的。

5.2 无法获取拦截器真实类型

该问题主要出在拦截器里面，因为在 dryioc 当中如果某个类型绑定了多个拦截器，那么就会形成一个层级关系。类似于下面截图的这样：

所以如果你需要在外层的拦截器获取真实对象，目前只能通过递归来解决该问题。

public static type getunproxiedtype(object instance)
{
    if (instance is iproxytargetaccessor proxytargetaccessor)
    {
        var newinstance = proxytargetaccessor.dynproxygettarget();
        return getunproxiedtype(newinstance);
    }

    return instance.gettype();          
}

然后使用方式如下：

public void intercept(iinvocation invocation)
{
    _authorizationhelper.authorize(invocation.methodinvocationtarget, typeextensions.getunproxiedtype(invocation.proxy));
    invocation.proceed();
}

该问题我在 github 上面已经向作者提出，作者反馈正在解决。

六、结语

虽然通过文章看起来整个过程十分简单轻松，但是博主当时在操作的时候遇到了不少的坑。结合博主之前关于 abp 源码分析的文章，你可以更加地了解 abp 整个框架的结构。

通过这种方式，你除了可以将 di 框架换成 dryioc 之外，你也可以替换成你喜欢的其他 di 框架。

在 abp vnext 当中的设计ioc 容器是可以很方便替换的，你可以更加方便地替换 ioc 容器，就不需要像现在这样麻烦。

ps: 官方就有针对于 autofac 与 castle windsor 的扩展。

改造完成的代码与 demo 的 github 地址：https://github.com/gamebelial/abp-dryioc.git