ABP文档 ：Overall - Module System

模块介绍

ABP提供了构建模块并将这些模块组合起来创建应用的基础设施。一个模块可以依赖另一个模块。一般来说，一个程序集可以认为是一个模块。如果应用中有多个程序集，建议为每个程序集创建一个模块定义。模块系统通常关注服务端。

模块定义

一个模块是由一个派生了AbpModule的类定义的。比如说我们在开发一个可以用在不同的应用中的博客模块。最简单的模块定义如下：

public class MyBlogApplicationModule : AbpModule
{
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

模块定义类 负责将模块中需要注册的的类注册到依赖注入容器中（如上例中，可依照惯例自动注册），它也可以配置应用和其他模块，以及为应用添加新特性等。

生命周期

ABP在应用启动和关闭的时候会调用一些特定的模块方法。可以通过重写这些方法来执行特定的任务。

ABP按照依赖的顺序调用这些方法。如果模块A依赖于模块B，那么模块B在模块A之前初始化。方法执行的正确顺序是：PreInitialize-B, PreInitialize-A, Initialize-B, Initialize-A, PostInitialize-B and PostInitialize-A。这对于所有的依赖图都是成立的。Shutdown方法也是类似的，但顺序相反。

PreInitialize

该方法会在应用启动时首先调用，它常常用于在框架和其他模块初始化前配置它们。

你可以在该方法里面写一些特定的代码，这些代码会在依赖注入注册之前执行。比如，如果你创建了一个“conventional registration”类，那么你应该把它在这里注册（使用locManager.AddConventionalRegister方法）。

Initialize

该方法通常是依赖注入注册的地方。一般使用IocManager.RegisterAssemblyByConvention方法完成。如果你想要定义自定义的依赖注册，请看后面的依赖注入文档。

PostInitialize

该方法在应用启动的最后调用。在这里可以安全地解析一个依赖。

Shutdown

该方法在应用关闭的时候调用。

模块依赖

一个模块可以依赖于其他模块。如下例，应用DependsOn属性显式地声明依赖关系。

[DependsOn(typeof(MyBlogCoreModule))]
public class MyBlogApplicationModule : AbpModule
{
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

这样，我们向ASP.NET Boilerplate声明MyBlogApplicationModule模块依赖于MyBlogCoreModule模块，MyBlogCoreModule需要在MyBlogApplicationModule之前被初始化。

ABP从启动模块开始,依序递归地解决依赖关系并初始化它们，启动模块会在最后初始化。

插件模块

当从启动模块开始查找并加载模块时，ABP也可以实现动态加载。
AbpBootstrapper 类中定义了PlugInSources 属性，它可以用来添加资源从而可以动态地加载插件模块。插件资源可以是任何实现了IPlugInSource 接口的类，比如PlugInFolderSource 类可以从指定文件夹中的程序集中查找插件模块。

ASP.NET Core

ABP ASP.NET Core module defines options in AddAbp extension method to add plugin sources in Startup class:

services.AddAbp<MyStartupModule>(options =>
{
    options.PlugInSources.Add(new FolderPlugInSource(@"C:\MyPlugIns"));
});

We could use AddFolder extension method for a simpler syntax:

services.AddAbp<MyStartupModule>(options =>
{
    options.PlugInSources.AddFolder(@"C:\MyPlugIns");
});

See ASP.NET Core document for more on Startup class.

ASP.NET MVC, Web API

For classic ASP.NET MVC applications, we can add plugin folders by overriding Application_Start in global.asax as shown below:

public class MvcApplication : AbpWebApplication<MyStartupModule>
{
    protected override void Application_Start(object sender, EventArgs e)
    {
        AbpBootstrapper.PlugInSources.AddFolder(@"C:\MyPlugIns");
        //...
        base.Application_Start(sender, e);
    }
}

Controllers in PlugIns

If your modules include MVC or Web API Controllers, ASP.NET can not investigate your controllers. To overcome this issue, you can change global.asax file like below:

using System.Web;
using Abp.PlugIns;
using Abp.Web;
using MyDemoApp.Web;

[assembly: PreApplicationStartMethod(typeof(PreStarter), "Start")]

namespace MyDemoApp.Web
{
    public class MvcApplication : AbpWebApplication<MyStartupModule>
    {
    }

    public static class PreStarter
    {
        public static void Start()
        {
            //...
            MvcApplication.AbpBootstrapper.PlugInSources.AddFolder(@"C:\MyPlugIns\");
            MvcApplication.AbpBootstrapper.PlugInSources.AddToBuildManager();
        }
    }
}

Additional Assemblies

Default implementations for IAssemblyFinder and ITypeFinder (which is used by ABP to investigate specific classes in the application) only finds module assemblies and types in those assemblies. We can override GetAdditionalAssemblies method in our module to include additional assemblies.

Custom Module Methods

Your modules also can have custom methods those can be used by other modules depend on this module. Assume that MyModule2 depends on MyModule1 and wants to call a method of MyModule1 in PreInitialize.

public class MyModule1 : AbpModule
{
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }

    public void MyModuleMethod1()
    {
        //this is a custom method of this module
    }
}

[DependsOn(typeof(MyModule1))]
public class MyModule2 : AbpModule
{
    private readonly MyModule1 _myModule1;

    public MyModule2(MyModule1 myModule1)
    {
        _myModule1 = myModule1;
    }

    public override void PreInitialize()
    {
        _myModule1.MyModuleMethod1(); //Call MyModule1's method
    }

    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

Here, we constructor-injected MyModule1 to MyModule2, so MyModule2 can call MyModule1's custom method. This is only possible if Module2 depends on Module1.

Module Configuration

While custom module methods can be used to configure modules, we suggest to use startup configuration system to define and set configuration for modules.

Module Lifetime

Module classes are automatically registered as singleton.