1.2 ABP总体介绍 - 层架构体系

## 1.1 ABP总体介绍 - 入门介绍

ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称。

ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点，它旨在成为一个通用的WEB应用程序基础框架和项目模板。

ASP.NET Boilerplate 基于DDD的经典分层架构思想，实现了众多DDD的概念（但没有实现所有DDD的概念）。

• ABP的官方网站：http://www.aspnetboilerplate.com
• ABP在Github上的开源项目：https://github.com/aspnetboilerplate

ABP框架于2014年5月4日首次在Github开源，截止到2015年5月25日，总共进行了1271次代码提交，49次版本发布，现在的版本号是0.6.1.1。

1.1.1 ABP采用了以下技术

服务器端：

• ASP.NET MVC 5、Web API 2、C# 5.0
• DDD领域驱动设计 （Entities、Repositories、Domain Services、Domain Events、Application Services、DTOs等）
• Castle windsor （依赖注入容器）
• Entity Framework 6 \ NHibernate，数据迁移
• Log4Net（日志记录）
• AutoMapper（实现Dto类与实体类的双向自动转换）

客户端：

• Bootstrap
• Less
• AngularJs
• jQuery
• Modernizr
• 其他JS库: jQuery.validate、jQuery.form、jQuery.blockUI、json2

1.1.2 ABP框架已实现了以下特性

• 多语言/本地化支持
• 多租户支持（每个租户的数据自动隔离，业务模块开发者不需要在保存和查询数时写相应代码）
• 软删除支持（继承相应的基类或实现相应接口，会自动实现软删除）
• 统一的异常处理（应用层几乎不需要处理自己写异常处理代码）
• 数据有效性验证（Asp.NET MVC只能做到Action方法的参数验证，ABP实现了Application层方法的参数有效性验证）
• 日志记录（自动记录程序异常）
• 模块化开发（每个模块有独立的EF DbContext，可单独指定数据库）
• Repository仓储模式（已实现了Entity Framework、NHibernate、MangoDB、内存数据库）
• Unit Of Work工作单元模式（为应用层和仓储层的方法自动实现数据库事务）
• EventBus实现领域事件(Domain Events)
• DLL嵌入资源管理
• 通过Application Services自动创建Web Api层（不需要写ApiController层了）
• 自动创建Javascript 的代理层来更方便使用Web Api
• 封装一些Javascript 函数，更方便地使用ajax、消息框、通知组件、忙状态的遮罩层

“Zero”的模块，实现了以下功能：

• 身份验证与授权管理（通过ASP.NET Identity实现的）
• 用户&角色管理
• 系统设置存取管理（系统级、租户级、用户级，作用范围自动管理）
• 审计日志（自动记录每一次接口的调用者和参数）

在其他项目中的很多优秀设计，在ABP项目中也已存在，而且可能实现得更好。ABP框架的代码，都通过xUnit进行了单元测试。作者一直在用ABP框架开发他们的实际项目，从Github和他官方论坛上的信息可以看到，有很多国外的开发者在将ABP用作生产项目的基础框架。如果需要直接使用ABP组件，可以通过Nuget安装（在VS的Nuget包管理界面搜索ABP）。

为了更好地将ABP适用于自己的项目，我对ABP的源码做了一些修改后使用的，没有直接使用ABP组件。

我希望更多国内的架构师能关注ABP这个项目，也许这其中有能帮助到你的地方，也许有你的参与，这个项目可以发展得更好。

今天只是作了一个大概介绍，希望有更多的朋友能去阅读源代码，然后参与讨论。

1.1.3 ABP适用的场景

中小规模WEB应用开发，可直接使用ABP框架。 较大型项目可以在ABP框架的源码基础上进行扩展，以实现分布式架构。

注：处理高并发并不是ABP的强项。需要非常高并发的DDD框架，建议去研究netfocus的ENode。

1.2 ABP总体介绍 - 层架构体系

1.2.1 前言

为了减少复杂性和提高代码的可重用性，采用分层架构是一种被广泛接受的技术。为了实现分层的体系结构，ABP遵循DDD（领域驱动设计）的原则，将工程分为四个层：

• 展现层(Presentation)：向用户提供一个接口(UI)，使用应用层来和用户(UI)进行交互。

• 应用层(Application)：应用层是表现层和领域层能够实现交互的中间者，协调业务对象去执行特定的应用任务

• 领域层(Domain)：包括业务对象和业务规则，这是应用程序的核心层。

• 基础设施层(Infrastructure)：提供通用技术来支持更高的层。例如基础设施层的仓储(Repository)可通过ORM来实现数据库交互，或者提供发送邮件的支持。

根据实际需要，可能会有额外添加的层。例如：

• 分布式服务层(Distributed Service) ：用于公开应用程序接口供远程客户端调用。比如通过ASP.NET Web API或WCF来实现。

这些都是常见的以领域为中心的分层体系结构。不同的项目在实现上可能会有细微的差别。

1.2.2 ABP的体系结构

层次结构概览如下图所示：

一个简单的解决方案，大致包含5个项目：

一个层可以被实现为一个或者多个程序集。对于大项目的第三方依赖创建多个应用程序集这是一个好的选择(例如：这里的EntityFramework)。还有，在有限界上下文中，每个上下文都有它自己的分层。

1.2.3 领域层

领域层是实现所有业务规则的地方。

实体（Entity）： 实体代表业务领域的数据和操作，在实践中，通常用来映射成数据库表。

仓储（Repository）： 仓储是像集合一样的对象，用来在数据源(数据库)上检索和存储实体。在领域层定义仓储，但是不实现它们。它们在基础设施层被实现。

领域服务（Domain service）： 当处理的业务规则跨越两个(及以上)实体时，应该写在领域服务方法里面。

领域事件（Domain Event）： 领域事件被用来定义特定于领域的事件，并且触发使用它们。领域服务与实体(以及其他领域对象)一起实现了不属于单个实体的业务规则。

工作单元（Unit of Work）： 工作单元是一种设计模式被用来管理数据库连接和事务，以及跟踪实体更改，并将这些更改保存到数据存储中。它被定义在领域层中，但是在基础设施层实现它们。

1.2.4 应用层

应用层提供一些应用服务（Application Services）方法供展现层调用。一个应用服务方法接收一个DTO(数据传输对象)作为输入参数，使用这个输入参数执行特定的领域层操作，并根据需要可返回另一个DTO。在展现层到领域层之间，不应该接收或返回实体(Entity)对象，应该进行DTO映射。 一个应用服务方法通常被认为是一个工作单元（Unit of Work）。用户输入参数的验证工作也应该在应用层实现。ABP提供了一个基础架构让我们很容易地实现输入参数有效性验证。建议使用一种像AutoMapper这样的工具来进行实体与DTO之间的映射。

1.2.5 基础设施层

当在领域层中为定义了仓储接口，应该在基础设施层中实现这些接口。可以使用ORM工具，例如EntityFramework或NHibernate。ABP的基类已经提供了对这两种ORM工具的支持。数据库迁移也被用于这一层。

1.2.6 WEB与展现层

Web层使用ASP.NET MVC和Web API来实现。可分别用于多页面应用程序(MPA)和单页面应用程序(SPA)。

在SPA中，所有资源被一次加载到客户端浏览器中（或者先只加载核心资源，其他资源懒加载），然后通过AJAX调用服务端WebApi接口获取数据，再根据数据生成HTML代码。不会整个页面刷新。现在已经有很多SPA的JS框架，例如： AngularJs、 DurandalJs、BackboneJs、EmberJs。 ABP可以使用任何类似的前端框架，但是ABP提供了一些帮助类，让我们更方便地使用AngularJs和DurandalJs。

在经典的多页面应用（MPA）中，客户端向服务器端发出请求，服务器端代码（ASP.NET MVC控制器）从数据库获得数据，并且使用Razor视图生成HTML。这些被生成后的HTML页面被发送回客户端显示。每显示一个新的页面都会整页刷新。

SPA和MPA涉及到完全不同的体系结构，也有不同的应用场景。一个管理后台适合用SPA，博客就更适合用MPA，因为它更利于被搜索引擎抓取。

SignalR是一种从服务器到客户端发送推送通知的完美工具。它能给用户提供丰富的实时的体验。 已经有很多客户端的Javascript框架或库，JQuery是其中最流行的，并且它有成千上万免费的插件。使用Bootstrap可以让我们更轻松地完成写Html和CSS的工作。

ABP也实现了根据Web API接口自动创建 Javascript的代码函数，来简化JS对Web Api的调用。还有把服务器端的菜单、语言、设置等生成到JS端。（但是在我自己的项目中，我是把这些自动生成功能关闭的，因为必要性不是很大，而这些又会比较影响性能）。

ABP会自动处理服务器端返回的异常，并以友好的界面提示用户。

1.2.7 其它

ABP使用Castle Windsor为整个程序框架提供依赖注入的功能。使用Log4Net日志记录组件，提供给其他各层调用以进行日志记录。

1.3 ABP总体介绍 - 模块系统

1.3.1 ABP模块系统简介

ABP框架提供了创建和组装模块的基础，一个模块能够依赖于另一个模块。在通常情况下，一个程序集就可以看成是一个模块。在ABP框架中，一个模块通过一个类来定义，而这个类要继承自AbpModule。

模块系统当前专注于服务端而不是客户端。

译者注： 如果学习过Orchard的朋友，应该知道module模块的强大了。模块的本质就是可重用性，你可以在任意的地方去调用，而且通过实现模块，你写的模块也可以给别人用。.net可以通过反射获取一个程序集中的类以及方法。

1.3.2 定义模块

Assembly程序集：Assembly是一个用来包含程序的名称，版本号，自我描述，文件关联关系和文件位置等信息的一个集合。最简单的理解就是：一个你自己写的类库生成的dll就可以看做是一个程序集，这个程序集可以包括很多类，类又包括很多方法等。

一个派生自 AbpModule 的类就是模块的定义。我们正在开发一个博客模块，该模块可以被使用在不同的应用程序中。最简单的模块定义示例如下：

public class MyBlogApplicationModule : AbpModule //定义
{
    public override void Initialize() //初始化
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
        //这行代码的写法基本上是不变的。它的作用是把当前程序集的特定类或接口注册到依赖注入容器中。
    }
}

如果需要的话，模块类负责类的依赖注入(通常可以像上面一样做)。我们能配置应用程序和其它模块，添加新的功能到应用程序等等。

1.3.3 方法的生命周期

在一个应用中，ABP框架调用了Module模块的一些指定的方法来进行启动和关闭模块的操作。我们可以重载这些方法来完成我们自己的任务。

ABP框架通过依赖关系的顺序来调用这些方法，假如：模块A依赖于模块B,那么模块B要在模块A之前初始化，模块启动的方法顺序如下：

1. PreInitialize-B

• PreInitialize-A
• Initialize-B
• Initialize-A
• PostInitialize-B
• PostInitialize-A

下面是具体方法的说明：

PreInitialize

预初始化：当应用启动后，第一次运行会先调用这个方法。在初始化(Initialize)方法调用之前，该方法通常是用来配置框架以及其它模块。

在依赖注入注册之前，你可以在这个方法中指定你需要注入的自定义启动类。例如：加入你创建了某个符合约定的注册类，你应该使用 IocManager.AddConventionalRegisterer 方法在这里注册它。

Initialize

初始化：在这个方法中一般是来进行依赖注入的注册，一般我们通过IocManager.RegisterAssemblyByConvention这个方法来实现。如果你想实现自定义的依赖注入，那么请参考依赖注入的相关文档。

PostInitialize

提交初始化：最后一个方法，这个方法用来解析依赖关系。

Shutdown

关闭：当应用关闭以后，这个方法被调用。

1.3.4 模块依赖

Abp框架会自动解析模块之间的依赖关系，但是我们还是建议你通过重载GetDependencies方法来明确的声明依赖关系。

[DependsOn(typeof(MyBlogCoreModule))]//通过注解来定义依赖关系
public class MyBlogApplicationModule : AbpModule
{
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

例如上面的代码，我们就声明了MyBlogApplicationModule和MyBlogCoreModule的依赖关系，MyBlogApplicationModule这个应用模块依赖于MyBlogCoreModule核心模块，并且，MyBlogCoreModule核心模块会在MyBlogApplicationModule模块之前进行初始化。

ABP可以从 startup module 递归的解析依赖关系，并按需初始化它们。最后初始化的模块是启动模块(startup module)。

1.3.5 插件模块

当模块从启动模块以及其依赖关系进行调查发现的时候，ABP也能够动态的加载其它指定模块。AbpBootstrapper 类定义了 PlugInSources 属性，我们能够是用该属性添加需要动态加载的模块。插件源可以是任何实现了 IPlugInSource 接口的类。PlugInFolderSource 类实现了该接口，它可以被用来加载指定文件夹下的程序集。

ASP.NET Core

ABP的ASP.NET Core模块也可以动态加载模块，你只需要在 Startup 类中使用已定义的扩展方法 AddAbp，如下所示：

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

我们可以使用扩展方法 AddFolder 更方便的实现上述功能：

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

了解更多关于Startup类的信息，请查看 ASP.NET 文档

ASP.NET MVC，Web API

对于经典的ASP.NET MVC应用，我们可以在 global.asax 重写 Application_Start 方法来添加插件文件夹，如下所示：

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

插件中的控制器

如果你的模块包括了MVC或者Web API控制器，ASP.NET不能发现这些控制器。为了克服这个问题，你可以在 global.asax 中添加代码来实现，如下所示：

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

对于IAssemblyFinder和ITypeFinder的默认实现(这两个接口的实现被ABP用来在应用程序中发现指定的类)仅仅只用来查找模块程序集以及在这些程序集中所使用的类型。我们可以在我们的模块中重写 GetAdditionalAssemblies 方法来包含附加程序集。

1.3.6 自定义的模块方法

我们自己定义的模块中可能有方法被其他依赖于当前模块的模块调用，下面的例子，假设模块2依赖于模块1，并且想在预初始化的时候调用模块1的方法。这样，就把模块1注入到了模块2，因此，模块2就能调用模块1的方法了。

译者注： ABP的模块系统与Orchard的模块有类似之处，但还是有比较大的差别。Orchard的框架修改了ASP.NET程序集的默认加载方式（模块的DLL没有放在Bin文件夹下，是放在WEB项目根文件夹下面的Modules文件夹下），实现了功能模块的热插拔，而ABP的模块程序集还是放在Bin文件夹下的，没有实现热插拔。

public class MyModule1 : AbpModule
{
    public override void Initialize() //初始化模块
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());//这里，进行依赖注入的注册。
    }
    public void MyModuleMethod1()
    {
        //这里写自定义的方法。
    }
}
[DependsOn(typeof(MyModule1))]
public class MyModule2 : AbpModule
{
    private readonly MyModule1 _myModule1;
    public MyModule2(MyModule1 myModule1)
    {
        _myModule1 = myModule1;
    }
    public override void PreInitialize()
    {
        _myModule1.MyModuleMethod1(); //调用MyModuleMethod1的方法。
    }
    public override void Initialize()
    {
            IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
     }
}

在这里，我们通过构造函数注入MyModule1到MyModule2，所以MyModule2能够调用MyModule1的自定义方法。当且仅当MyModule2依赖于MyModule1才是可能的。

1.3.7 模块配置

虽然自定义模块可以被用来配置模块，但是，作者建议使用启动配置来定义和配置模块。

1.3.8 模块生命周期

所有的模块类都被自动的注册为单例模式。

1.4 ABP总体介绍 - 启动配置

在应用启动之前，abp框架提供了模块基本的配置和方法，大家参照下面这个例子就可以了。

译者注： 在看这一节的内容之前，建议大家先下载module-zero这个例子代码，这个例子就是一个用户和角色的模块，并且使用的实例。配置在每一个应用中都可能会有，比如你有一个网站，你要获取网站的一些自定义基本参数，比如logo位置，网站名称，上传文件大小等等。模块化的配置方式和我们之前的做法肯定是不同的，大家要注意。之前无非就是一个方法getconfig从对应的表取数据，然后使用。

1.4.1 配置ABP

配置是通过在自己模块的PreInitialize方法中来实现的（对于module的PreInitialize方法，在上一篇中已经向大家做了简单的说明）代码示例如下：

public class SimpleTaskSystemModule : AbpModule
{
    public override void PreInitialize()
    {
        //在你的应用中添加语言包，这个是英语和作者的土耳其语。
        Configuration.Localization.Languages.Add(new LanguageInfo("en", "English", "famfamfam-flag-england", true));
        Configuration.Localization.Languages.Add(new LanguageInfo("tr", "Türkçe", "famfamfam-flag-tr"));
        Configuration.Localization.Sources.Add(
            new XmlLocalizationSource(
                "SimpleTaskSystem",
                HttpContext.Current.Server.MapPath("~/Localization/SimpleTaskSystem")
                )
            );
        //配置导航和菜单
        Configuration.Navigation.Providers.Add<SimpleTaskSystemNavigationProvider>();
    }
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

和orchard类似，abp框架一开始就被设计成模块化的，不同的模块可以通过abp框架来进行配置。举个例子吧，不同的模块都可以添加导航，通过导航添加菜单项到自己定义的主菜单，具体的细节大家可以参照：

• 本地化
• 导航

替换内置服务

Configuration.ReplaceService 方法可以被用来重写某个内置的服务。例如，你可以替换掉IAbpSession服务使用你自己扩展的服务。如下所示：

Configuration.ReplaceService<IAbpSession, MySession>(DependencyLifeStyle.Transient);

ReplaceService 方法通过传递一个 Action 来实现替换，这样我们就可以使用自定义的扩展类型替换掉原来的类型(你也可以直接使用Castle Windsor直接调用更高级的API函数)。

同一个服务可以被替换多次(尤其是在不同的模块)。最后替换的类型才是最终的使用类型。

1.4.2 配置模块

和.net框架原生的启动配置相比较，abp有哪些不一样呢？abp框架的模块可以通过IAbpModuleConfigurations接口进行个性化的扩展，这样的话，模块配置更加简单、方便。

示例代码如下：

...
using Abp.Web.Configuration;
...
public override void PreInitialize() 
{
    Configuration.Modules.AbpWebCommon().SendAllExceptionsToClients = true;
}
...

在上面这个例子中，我们通过配置AbpWebCommon模块，发送异常到客户端。当然了，不是每一个模块都需要这种配置，通常情况下我们需要，是当一个模块需要在多个不同的应用中重复使用，我们才进行这样的配置。

1.4.3 为一个模块创建配置

如下代码，假如我们有一个命名为MyModule的模块，并且这各模块有一些自己的配置。那么我们首先要创建一些类，这些类定义为属性（译者注：属性有自动的get和set访问器。），代表了不同的配置。

public class MyModuleConfig
{
    public bool SampleConfig1 { get; set; }
    public string SampleConfig2 { get; set; }
}

接下来，我们通过依赖注入，注册这个类。IocManager.Register();

译者注： 在IocManager中注册了一个类，换句话说，我们通过IocManager可以得到这个类MyModuleConfig的实例。至于IOC的原理这里就不在详细说了，总之，就是可以得到一个类的实例。

最后，我们通过创建一个扩展的方法IModuleConfigurations来得到配置的引用。如下代码：

译者注： 模块配置是一个静态类，因为我们需要重复使用它。静态方法Mymodule返回的是一个配置接口，参数是ImoduleConfigurations接口。

现在，在其他模块中也可以配置我们自定义的这个MyModule模块了。 Configuration.Modules.MyModule().SampleConfig1 = false; Configuration.Modules.MyModule().SampleConfig2 = "test";

在某种意义上，MyModule需要这些配置，通过注射MyModuleConfig我们就可以使用这些值。

    public class MyService : ITransientDependency
    {
        private readonly MyModuleConfig _configuration;
        public MyService(MyModuleConfig configuration)
        {
            _configuration = configuration;
        }
        public void DoIt()
        {
            if (_configuration.SampleConfig2 == "test")
            {
                //...
            }
        }
    }

这意味着，在abp框架的系统中，所有的模块都可以集中配置。

1.5 ABP总体介绍 - 多租户

1.5.1 什么是多租户

维基百科：“软件多租户是指一个软件架构的实例软件运行在一个服务器上，但存在多个租户。租户是一组共享一个公共的用户访问特定权限的软件实例。多租户架构,软件应用程序旨在提供每个租户专用的实例包括数据、配置、用户管理、租户个体功能和非功能属性。多租户与多实例架构,独立的软件实例代表不同的租户”操作多租户一般用来创建SaaS(软件即服务）应用程序（云计算），下面有一些案例：

1.5.2 多个部署多个数据库

这实际上并不是多租户，如果为每个客户（租户）配置一个单独的数据库和应用程序的一个实例，即在单个服务器中部署但提供给多个客户(租户)使用，我们需要确保应用程序的多个实例不会因为系统相同的配置环境而发生冲突。

这种已有的设计方式也不是真正为多租户服务的，它的好处是更容易的创建，但是存在一些安装、使用和维护的问题。

1.5.3 单个部署多个数据库

使用这种方式，我们可以在服务器上运行应用程序的一个实例。我们有一个主数据库用来存储租户的数据(例如：租户名称以及子域名)以及每个租户的单个数据库。一旦我们识别出当前租户(例如：从子域名或者用户登录的信息来判定)，那么我们可以切换到当前租户的数据库来执行操作。

以这种方式设计出来的应用程序，在某种程度上可以被看做多租户。但是大多数的应用仍然依赖于多租户。

我们应该为每个租户创建和维护它们自己单独的数据库，这包括数据迁移。如果我们有很多的客户以及与之相应的数据库，在更新应用程序的时候，那会花费太多的时间在数据库架构的迁移上。当然这样做，我们为租户分离出了数据库，我们可以为每个租户备份它们自己的数据库。如果租户需要的话，我们可以将租户的数据库迁移到更强大的服务器上。

1.5.4 单个部署单个数据库

这是真正的多租户构架，我们只在服务器上部署应用程序的单一实例且只有一个数据库。在各表中使用TenantId来隔离其它租户的信息。

这样的好处是易于安装和维护，但创建这样的一个应用程序比较困难。因为，需要防止租户读写其它租户的信息。在用户读取数据时候可以添加TenantId过滤器过滤数据，同样，系统会检测用户的写入操作。这是很繁琐的，而且也容易出错。ABP可以帮助我们自动数据过滤。

如果我们有很多租户并且数据量巨大，那么这种实现方式将会导致一些性能问题。我们可以使用表分区或者数据库的其它功能来克服这些问题。

1.5.5 单部署混合数据库

通常我们可能想存储租户到一个单独的数据库中，但是也可能想为租户创建分离的数据库。例如：我们可以为那些数据量巨大的租户创建单独的数据库，但是其它租户仍使用同一个数据库。

1.5.6 多部署-单/多/混合数据库

最后，为了达到更好的性能，高可用性以及伸缩性；我们可能想要部署我们的应用到多个服务器上。这些都是依赖于数据库的方式。

1.5.7 ABP中的多租户

ABP可以工作于所有上面所描述的场景。

1. 开启多租户

默认多租户是被禁用的，我们需要在模块的 PreInitialize 方法中开启它，如下所示：

Configuration.MultiTenancy.IsEnabled = true;

2. Host VS 租户

首先，我们先定义两个多租户系统中的术语：

• 租户：客户有它自己的用户,角色,权限,设置…并使用应用程序与其他租户完全隔离。多租户应用程序将有一个或多个租户。如果这是一个CRM应用程序,不同的租户也他们自己的帐户、联系人、产品和订单。所以,当我们说一个租户的用户,我们的意思是用户拥有的租户。

• Host: Host是单例的（只有唯一一个Host).Host负责创建和管理租户。所以Host用户独立与租户且可以控制租户。

3. Session

ABP定义IAbpSession接口来获取当前用户和租户id。这个接口中使用多租户当前租户的id。因此,它可以基于当前租户的id过滤数据。

这里有一些规则：

• 如果两个用户id和TenantId是null，那么当前用户没有登录到系统中。所以，我们不知道这是一个主机用户或租户的用户。在这种情况下，用户不能访问授权的内容。

• 用户id(如果不为空，TenantId为空的，然后我们可以知道当前用户是一个主机用户。

• 用户id(如果不为空，TenantId也不为空，我们可以知道当前用户是一个租户的用户。

有关更多的Session内容可查看：Session

4. 当前租户的断定

由于所有的租户用户都是使用了相同的应用程序，我们应该有一种方式来区分当前请求的租户。默认会话(ClaimsAbpSession)用给定的顺序实现了使用不同的方式来找到当前请求相关的租户：

• 1. 如果用户已经登录，那么从当前声明(claims)中取得租户ID，声明的唯一名字是：http://www.aspnetboilerplate.com/identity/claims/tenantId 并且该声明应该包含一个整型值。如果在声明中没有发现，那么该用户被假设为Host用户。

• 2. 如果用户没有登录，那么它会尝试从 tenant resolve contributors(暂翻译为：租户解析参与者) 中解析租户ID。这里有3种预定义的租户参与者，并按照给定的顺序运行(第一个解析成功的解析器获胜)：

  • 1. DomainTenantResolveContributer：尝试从url中解析租户名，通常来说是域名或者子域名。在模块的预初始化(PreInitialize)中可以配置域名格式(例如：Configuration.Modules.AbpWebCommon().MultiTenancy.DomainFormat = “{0}.mydomain.com”;)。如果域名的格式是 “{0}.mydomain.com”，并且当前请求的域名是：acme.mydomain.com，那么租户名被解析为 acme。那么下一步就是通过 ITenantStore 用给定的租户名来查找租户ID，如果租户被发现，那么该租户ID就是当前租户的ID。

  • 2. HttpHeaderTenantResolveContributer：如果存在 Abp.TenantId 请求头(这个常量被定义在Abp.MultiTenancy.MultiTenancyConsts.TenantIdResolveKey)，那么尝试从该请求头中解析租户ID。

  • 3. HttpCookieTenantResolveContributer：如果存在 Abp.TenantId 的cookie值(这个常量被定义在Abp.MultiTenancy.MultiTenancyConsts.TenantIdResolveKey)，那么就从该cookie中解析租户ID。

如果上述方式都没有解析得到租户ID，那么当前的请求会被考虑作为Host请求。租户解析器是可扩展的。你可以添加解析器到集合：Configuration.MultiTenancy.Resolvers，或者移除某个存在的解析器。

关于解析租户ID的最后一件事情是：为了性能优化，解析的租户ID被缓存在相同的请求中。所以，在同一个请求中解析仅被执行一次(当且仅当该用户没有登录)。

5. Tenant Store

DomainTenantResolveContributer 使用 ITenantStore 通过租户名来查找租户ID。NullTenantStore 默认实现了 ITenantStore 接口，但是它不包含任何租户，对于查询仅仅返回null值。当你需要从数据源中查询时，你可以实现并替换它。在 Module Zero 的 Tenant Manager 中已经实现了该扩展。所以，如果你使用了module zero，那么你不需要关心tenant store。

6. 数据过滤

当我们从数据库检索实体，我们必须添加一个TenantId过滤当前的租户实体。当你实现了接口：IMustHaveTenant或IMayHaveTenant中的一个时，ABP将自动完成数据过滤。

IMustHaveTenant Interface

这个接口通过TenantId属性来区分不同的租户的实体。示例：

public class Product : Entity, IMustHaveTenant
{
    public int TenantId { get; set; }
    public string Name { get; set; }
    //...其它属性
}

因此，ABP能发现这是一个与租户相关的实体，并自动隔离其它租户的实体。

IMayHaveTenant interface

我们可能需要在Host和租户之间共享实体类型。一个实体可能属于租户或Host,IMayHaveTenant接口还定义了TenantId(类似于IMustHaveTenant),但在这种情况下可以为空。示例如下：

public class Role : Entity, IMayHaveTenant
{
    public int? TenantId { get; set; }
    public string RoleName { get; set; }
    //...其它属性
}

我们可以使用相同的角色类存储主机角色和租户的角色。在这种情况下，TenantId属性会告诉我们这是一个Host实体还是一个租户实体。null 值意味着这是一个 Host实体 ，一个 非空值 意味着这被一个租户拥有，该租户的Id是 TenantId 。

备注

IMayHaveTenant不像IMustHaveTenant一样常用。比如，一个Product类可以不实现IMayHaveTenant接口，因为Product和实际的应用功能相关，和管理租户不相干。因此，要小心使用IMayHaveTenant接口，因为它更难维护租户和租主共享的代码。

当你定义一个实体类型实现了 IMustHaveTenant 或者 IMayHaveTenant 接口的时候；那么在创建一个新实体的时候，你就需要设置 TenantId 的值，(ABP会尝试把当前AbpSession的TenantId的值设置给它，但是在某些情况下这是不可能的，尤其是实现了IMayHaveTenant接口的实体)。在大多数时候，这是唯一一个地方你需要处理TenantI的地方，但是在其它对租户数据过滤的时候，你不需要在写Linq的where条件语句的时候明确指出TenantId，因为它会自动的实现过滤。

在Host和租户之间的切换

当在多租户应用数据库上工作的时候，我们应该知道当前的租。默认获取租户ID的方式是从 IAbpSession 上获取的。我们可以改变这个行为并且切换到其它租户的数据库上。例如：

public class ProductService : ITransientDependency
{
    private readonly IRepository<Product> _productRepository;
    private readonly IUnitOfWorkManager _unitOfWorkManager;
    public ProductService(IRepository<Product> productRepository, IUnitOfWorkManager unitOfWorkManager)
    {
        _productRepository = productRepository;
        _unitOfWorkManager = unitOfWorkManager;
    }
    [UnitOfWork]
    public virtual List<Product> GetProducts(int tenantId)
    {
        using (_unitOfWorkManager.Current.SetTenantId(tenantId))
        {
            return _productRepository.GetAllList();
        }
    }
}

SetTenantId 方法确保我们得到的数据是指定租户的数据，这依赖于数据库架构：

• 如果给定的租户有特定的数据库，那么切换到这个数据库并且从该数据库中取得产品数据

• 如果给定的租户没有特定的数据库(例如：单数据库方式)，它会自动的添加TenantId条件到查询语句来过滤数据获取指定的租户的产品数据

如果我们没有使用SetTenantId方法，它会从Session中取得租户Id，如同之前所述。

这里有一些关于最佳实践的建议：

• 使用 SetTenantId(null) 切换到Host

• 如果没有特别的原因，你应该像上面示例所展示的一样，在using语句块中使用SetTenantId方法。因为它会在using语句块后且在 GetProducts 方法工作完成之前，自动的还原TenantId (也就是说using语句块运行完后，TenantId是从Session中获取的不会是来自于GetProducts的传入参数)

• 如果需要你可以嵌套使用SetTenantId方法

• 因为 _unitOfWorkManager.Current 仅在工作单元中有效，请确保你的代码是在工作单元中运行

1.6 ABP总体介绍 - 集成OWIN

1.6.1 简介

如果你在你的应用中使用了 ASP.NET MVC 和 ASP.NET Web API，那么你需要添加 Abp.Owin 包到你的项目。

1.6.2 安装

添加 Abp.Owin 包到你的主项目(一般来说是 Web 项目)。

Install-Package Abp.Owin

1.6.3 使用

在OWIN Startup 文件中调用 UserApp() 的扩展方法，如下所示：

[assembly: OwinStartup(typeof(Startup))]
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseAbp();
        //其它配置...
    }
}

如果你只使用了OWIN(也就说是一个自宿主Web API项目)，你可以在ABP的启动模块的初始化方法中重写UseAbp。注意，这只有在ABP没有其它的初始化方式的时候才可以这么做。

2.1 ABP公共结构 - 依赖注入

如果你已经了解依赖注入的概念、构造函数和属性注入模式，你可以跳过这一节。

维基百科：“依赖注入是一种软件设计模式，指一个或多个依赖（或服务）被注入，或通过引用传递，传入一个依赖对象（或客户端）并成为客户状态的一部分。模式通过自身的行为分离了客户依赖的创建，这允许程序设计是松耦合的，同时遵循依赖倒置和单一职责原则。与服务定位器模式直接进行对比，它允许客户了解他们用来查找依赖的机制。”

如果不使用依赖注入技术，很难进行依赖管理、模块化开发和应用程序模块化。

2.1.1 传统方式的问题

在一个应用程序中，类之间相互依赖。假设我们有一个应用程序服务，使用仓储（repository）类插入实体到数据库。在这种情况下，应用程序服务类依赖于仓储（repository）类。看下例子：

public class PersonAppService
{
    private IPersonRepository _personRepository;
    public PersonAppService()
    {
        _personRepository = new PersonRepository();            
    }
    public void CreatePerson(string name, int age)
    {
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
    }
}

PersonAppService使用PersonRepository插入Person到数据库。这段代码的问题：

• PersonAppService通过IPersonRepository调用CreatePerson方法，所以这方法依赖于IPersonRepository，代替了PersonRepository具体类。但PersonAppService（的构造函数）仍然依赖于PersonRepository。组件应该依赖于接口而不是实现。这就是所谓的依赖性倒置原则。

• 如果PersonAppService亲自创建PersonPeository，这变得依赖到了一个特定的IPersonRepository接口实现，且不能使用另一个实现进行工作。因此，从实现分离接口变得无意义，硬依赖使得代码基于紧耦合和低重用。硬依赖（hard-dependency）使得代码紧密耦合和较低的可重用。

• 我们可能需要在未来改变创建PersonRepository的方式。即，我们可能想让它创建为单例(单一共享实例而不是为每个使用创建一个对象)。或者我们可能想要创建多个类实现IPersonRepository并根据条件创建对象。在这种情况下，我们需要修改所有依赖于IPersonRepository的类。

• 有了这样的依赖，很难(或不可能)对PersonAppService进行单元测试。

为了克服这些问题，可以使用工厂模式。因此，创建的仓储类是抽象的。看下面的代码：

 public class PersonAppService
{
    private IPersonRepository _personRepository;
    public PersonAppService()
    {
        _personRepository = PersonRepositoryFactory.Create();            
    }
    public void CreatePerson(string name, int age)
    {
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
    }
}

PersonRepositoryFactory是一个静态类，创建并返回一个IPersonRepository。这就是所谓的服务定位器模式。以上依赖问题得到解决，因为PersonAppService不需要创建一个IPersonRepository的实现的对象，这个对象取决于PersonRepositoryFactory的Create方法。但是，仍然存在一些问题：

• 此时，PersonAppService取决于PersonRepositoryFactory。这是更容易接受，但仍有一个硬依赖（hard-dependency）。

• 为每个库或每个依赖项乏味的写一个工厂类/方法。

• 测试性依然不好，由于很难使得PersonAppService使用mock实现IPersonRepository。

2.1.2 解决方案

有一些最佳实践(模式)用于类依赖。

1. 构造函数注入(Constructor injection)

重写上面的例子，如下所示:

public class PersonAppService
{
    private IPersonRepository _personRepository;
    public PersonAppService(IPersonRepository personRepository)
    {
        _personRepository = personRepository;
    }
    public void CreatePerson(string name, int age)
    {
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
    }
}

这被称为构造函数注入。现在，PersonAppService不知道哪些类实现IPersonRepository以及如何创建它。谁需要使用PersonAppService，首先创建一个IPersonRepository PersonAppService并将其传递给构造函数，如下所示：

var repository = new PersonRepository();
var personService = new PersonAppService(repository);
personService.CreatePerson("Yunus Emre"， 19);

构造函数注入是一个完美的方法，使一个类独立创建依赖对象。但是，上面的代码有一些问题：

• 创建一个PersonAppService变得困难。想想如果它有4个依赖，我们必须创建这四个依赖对象，并将它们传递到构造函数PersonAppService。

• 从属类可能有其他依赖项(在这里，PersonRepository可能有依赖关系)。所以，我们必须创建PersonAppService的所有依赖项，所有依赖项的依赖关系等等. .如此，依赖关系使得我们创建一个对象变得过于复杂了。

幸运的是，依赖注入框架能够自动化管理依赖关系。

2. 属性注入(Property injection)

采用构造函数的注入模式是一个完美的提供类的依赖关系的方式。通过这种方式，只有提供了依赖你才能创建类的实例。同时这也是一个强大的方式显式地声明，类需要什么样的依赖才能正确的工作。

但是，在有些情况下，该类依赖于另一个类，但也可以没有它。这通常是适用于横切关注点(如日志记录)。一个类可以没有工作日志，但它可以写日志如果你提供一个日志对象。在这种情况下，你可以定义依赖为公共属性，而不是让他们放在构造函数。想想，如果我们想在PersonAppService写日志。我们可以重写类如下:

public class PersonAppService
{
    public ILogger Logger { get; set; }
    private IPersonRepository _personRepository;
    public PersonAppService(IPersonRepository personRepository)
    {
        _personRepository = personRepository;
        Logger = NullLogger.Instance;
    }
    public void CreatePerson(string name, int age)
    {
        Logger.Debug("Inserting a new person to database with name = " + name);
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
        Logger.Debug("Successfully inserted!");
    }
}

NullLogger.Instance 是一个单例对象，实现了ILogger接口，但实际上什么都没做(不写日志。它实现了ILogger实例，且方法体为空)。现在，PersonAppService可以写日志了，如果你为PersonAppService实例设置了Logger，如下面:

Var personService = new PersonAppService(new PersonRepository());
    personService.Logger = new Log4NetLogger();
    personService.CreatePerson("Yunus Emre", 19);

假设Log4NetLogger实现ILogger实例，使得我们可以使用Log4Net库写日志。因此，PersonAppService可以写日志。如果我们不设置Logger，PersonAppService就不写日志。因此，我们可以说PersonAppService ILogger实例是一个可选的依赖。

几乎所有的依赖注入框架都支持属性注入模式。

3. 依赖注入框架

有许多依赖注入框架，都可以自动解决依赖关系。他们可以创建所有依赖项(递归地依赖和依赖关系)。所以你只需要依赖注入模式写类和类构造函数&属性，其他的交给DI框架处理！在良好的应用程序中，类甚至独立于DI框架。整个应用程序只会有几行代码或类，显示的与DI框架交互。

ABP的依赖注入基于 Castle Windsor框架。Castle Windsor最成熟的DI框架之一。还有很多这样的框架，如Unity，Ninject，StructureMap，Autofac等等。

在使用一个依赖注入框架时，首先注册你的接口/类到依赖注入框架中，然后你就可以resolve一个对象。在Castle Windsor，它是这样的：

var container = new WindsorContainer();
    container.Register(
            Component.For<IPersonRepository>().ImplementedBy<PersonRepository>().LifestyleTransient(),
            Component.For<IPersonAppService>().ImplementedBy<PersonAppService>().LifestyleTransient()
        );
    var personService = container.Resolve<IPersonAppService>();
    personService.CreatePerson("Yunus Emre", 19);

我们首先创建了WindsorContainer。然后注册PersonRepository 和 PersonAppService及它们的接口。然后我们要求容器创建一个IPersonAppService实例。它创建PersonAppService对象及其依赖项并返回。在这个简单的示例中，使用DI框架也许不是那么简洁，但想象下，在实际的企业应用程序中你会有很多类和依赖关系。当然，注册的依赖项只在程序启动的某个地方创建一次。

请注意，我们只是将对象声明为临时对象(transient)。这意味着每当我们创建这些类型的一个对象时，就会创建一个新的实例。在这里会有许多不同的生命周期(如：Singletion单例模式)。

4. ABP依赖注入的基础结构

在编写应用程序时遵循最佳实践和一些约定，ABP几乎让依赖注入框架使用变得无形。

注册(Registering)

在ABP中，有很多种不同的方法来注册你的类到依赖注入系统。大部分时间，常规方法就足够了。

常规注册(Conventional registrations)

按照约定，ABP自动注册所有 Repositories， Domain Services， Application Services， MVC 控制器和Web API控制器。例如，你可能有一个IPersonAppService 接口和实现类PersonAppService：

public interface IPersonAppService : IApplicationService
{
    //...
}
public class PersonAppService : IPersonAppService
{
    //...
}

ABP会自动注册它，因为它实现IApplicationService接口(它只是一个空的接口)。它会被注册为transient (每次使用都创建实例)。当你注入(使用构造函数注入)IPersonAppService接口成一个类，PersonAppService对象会被自动创建并传递给构造函数。

注意：命名约定在这里非常重要。例如你可以将名字PersonAppService改为 MyPersonAppService或另一个包含“PersonAppService”后缀的名称，由于IPersonAppService包含这个后缀。但是你可以不遵循PeopleService命名你的服务类。如果你这样做，它将不会为IPersonAppService自动注册(它需要自注册（self-registration）到DI框架，而不是接口)，所以，如果你想要你应该手动注册它。

ABP按照约定注册程序集。所以，你应该告诉ABP按照约定注册你的程序集。这很容易:

IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());

Assembly.GetExecutingAssembly()得到一个对包括此代码的程序集的引用。你可以通过RegisterAssemblyByConvention方法注册其他程序集。这同在你的模块初始化（AbpModule.Initialize()）时完成。请查看ABP的模块系统获得更多信息。

你可以通过实现 IConventionalRegisterer 接口和调用 IocManager.AddConventionalRegisterer 方法编写自己的约定注册类。你应该将它添加到模块的pre-initialize方法中。

帮助接口(Helper interfaces)

你可以注册一个特定的类，不遵循传统的约定制度规则。ABP提供了 ITransientDependency和ISingletonDependency 接口的快速实现方法。例如：

public interface IPersonManager
{
    //...
}
public class MyPersonManager : IPersonManager, ISingletonDependency
{
    //...
}

以这种方式，你可以很容易地注册MyPersonManager为transient。当需要注入IPersonManager时，MyPersonManager会被使用。注意，依赖被声明为单例。因此，创建的MyPersonManager同一个对象被传递给所有需要的类。只是在第一次使用时创建，那么应用程序的整生命周期使用的是同一实例。

自定义/直接 注册(Custom/Direct registration)

如果之前描述的方法还是不足以应对你的情况，你可以使用 IocManager或者Castle Windsor 来注册你自己的类。

使用IocManager

你可以使用 IocManager 来注册依赖关系(这通常是在模块的PreInitialize方法中实现)：

IocManager.Register<IMyService, MyService>(DependencyLifeStyle.Transient);

使用Castle Windsor API

你也可以使用 IIocManager.IocContainer 属性来访问Windsor容器并且注册依赖关系。如下所示：

IocManager.IocContainer.Register(Classes.FromThisAssembly().BasedOn<IMySpecialInterface>().LifestylePerThread().WithServiceSelf());

更多信息，请阅读Windsor文档。

这里没有删除之前实现IWindsorInstaller接口的翻译，因为我感觉这个非常有用。

也可以实现IWindsorInstaller接口进行注册。你可以在应用程序中创建一个实现IWindsorInstaller接口的类：

public class MyInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(Classes.FromThisAssembly().BasedOn<IMySpecialInterface>().LifestylePerThread().WithServiceSelf());
    }
}

Abp自动发现和执行这个类。最后，你可以通过使用IIocManager.IocContainer属性得到WindsorContainer。

解析（Resolving）

注册通知IOC(控制反转)容器关于你的类，它们的依赖项和生命周期。在你的应用程序需要使用IOC容器创建对象时，ASP.NET提供了一些方法解决依赖关系。

构造函数 & 属性注入(Constructor & Property Injection)

作为最佳实践，应该使用构造函数和属性注入去获取类的依赖。例子：

public class PersonAppService
{
    public ILogger Logger { get; set; }
    private IPersonRepository _personRepository;
    public PersonAppService(IPersonRepository personRepository)
    {
        _personRepository = personRepository;
        Logger = NullLogger.Instance;
    }
    public void CreatePerson(string name, int age)
    {
        Logger.Debug("Inserting a new person to database with name = " + name);
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
        Logger.Debug("Successfully inserted!");
    }
}

IPersonRepository从构造函数注入，ILogger实例从公共属性注入。这样，你的代码不会体现依赖注入系统。这是使用DI系统最适当的方式。

IIocResolver，IIocManager以及IScopedIocResolver接口

有时可能需要直接创建所需的依赖项，而不是构造函数和属性注入。（应该尽可能避免这种情况）。Abp提供一些服务使得这样的注入很容易实现。例子：

public class MySampleClass : ITransientDependency
{
    private readonly IIocResolver _iocResolver;
    public MySampleClass(IIocResolver iocResolver)
    {
        _iocResolver = iocResolver;
    }
    public void DoIt()
    {
        //解析, 使用并手动释放
        var personService1 = _iocResolver.Resolve<PersonAppService>();
        personService1.CreatePerson(new CreatePersonInput { Name = "Yunus", Surname = "Emre" });
        _iocResolver.Release(personService1);
        //解析并使用using语法糖来释放资源
        using (var personService2 = _iocResolver.ResolveAsDisposable<PersonAppService>())
        {
            personService2.Object.CreatePerson(new CreatePersonInput { Name = "Yunus", Surname = "Emre" });
        }
    }
}

MySampleClass是一个应用程序的示例类。IIcResolver通过构造函数注入，然后用它来创建和释放对象。有几个解决方法的重载可以根据需要使用。Release方法用于释放组件(对象)。如果你是手动创建一个对象，调用Release方法释放对象非常重要。否则，你的应用程序会有内存泄漏问题。为了保证对象被释放，尽可能使用ResolveAsDisposable(就像上面的例子所示)。它会在using代码块结束的时候自动调用Release方法。

IIocResolver(以及IIocManager)有个 CreateScope 的扩展方法(定义在Abp.Dependency命名空间)来安全的释放所有的解析后了依赖资源。如下所示：

using (var scope = _iocResolver.CreateScope())
{
    var simpleObj1 = scope.Resolve<SimpleService1>();
    var simpleObj2 = scope.Resolve<SimpleService2>();
    //...
}

在using语句块的最后，所有解析后的依赖资源会自动的释放。也可以使用 IScopedIocResolver 接口来实现上述操作。你能注入该接口并解析依赖关系。当你使用的类被释放后，所有被解析的依赖资源也会被自动释放掉。但是，请小心使用它；例如：如果该类的生命周期很长(如单例模式)，并且需要解析很多对象，那么它们会一直停留在内存中，直到该类被释放掉。

如果你想直接使用IOC容器(Castle Windsor)来处理依赖关系项，可以通过构造函数注入 IIocManager并使用它IIocManager.IocContainer 属性。如果你是在一个静态上下文或不能注入IIocManager，还有最后一个方法，你可以使用单例对象IocManager.Instance，你可以在任何地方获取到，它无处不在。但是，在这种情况下你的代码将变得不容易测试。

3.1.3 其他

1. IShouldInitialize 接口

有些类在第一次使用前需要初始化。IShouldInitialize有Initialize()方法。如果你实现它，那么你的Initialize()方法自动会被自动调用在创建对象之后(在使用之前)。当然，为了使用这个特性，你应该注入/创建此对象。

2. ASP.NET MVC & ASP.NET Web API 集成

当然，我们必须调用依赖注入系统处理依赖关系图的根对象。在一个ASP.NET MVC应用程序，通常是一个控制器类。我们可以使用构造函数注入模式注入控制器。当一个请求来到我们的应用程序中，控制器和所有依赖项被IOC容器递归创建。所以，谁做了这些？这是被Abp扩展的ASP.NET MVC默认控制器工厂自动完成的。ASP.NET Web API 也是相似的。你不用关心对象的创建和释放。

3. ASP.NET Core 集成

ASP.NET Core已经内置了依赖注入：Microsoft.Extensions.DependencyInjection。在ASP.NET Core中ABP使用Castle.Windsor.MsDependencyInjection实现了依赖注入。所以你不需要考虑它。

4. 最后说明（Last notes）

Abp简化并自动使用依赖注入，只要你遵守规则和使用上面的结构。大多数时候这样就够了。但是如果不能满足你的需求，你可以直接使用Castle Windsor的所有能力来执行任何任务(如自定义注册，注入钩子，拦截器等等)。

2.2 ABP公共结构 - 会话管理

2.2.1 简介

如果一个应用程序需要登录，则它必须知道当前用户执行了什么操作。因此ASP.NET在展示层提供了一套自己的SESSION会话对象，而ABP则提供了一个可以在任何地方获取当前用户和租户的IAbpSession接口

注意：关于IAbpSession接口：需要获取会话信息则必须实现IAbpSession接口。虽然你可以用自己的方式去实现它（IAbpSession），但是它在module-zero项目中已经有了完整的实现。

IAbpSession也被集成且使用在ABP其他模块中，例如：设置管理，权限认证。

2.2.2 注入会话

IAbpSession通常是以属性注入的方式存在于需要它的类中，不需要获取会话信息的类中则不需要它。如果我们使用属性注入方式，我们可以用NullAbpSession.Instance作为默认值来初始化它（IAbpSession），如下所示：

public class MyClass : ITransientDependency
{
    public IAbpSession AbpSession { get; set; }
    public MyClass()
    {
        AbpSession = NullAbpSession.Instance;
    }
    public void MyMethod()
    {
        var currentUserId = AbpSession.UserId;
        //...
    }
}

由于授权是应用层的任务，因此我们应该在应用层和应用层的上一层使用IAbpSession（我们不在领域层使用IAbpSession是很正常的）。

ApplicationService, AbpController 和 AbpApiController 这3个基类已经注入了AbpSession属性，因此在Application Service的实例方法中，能直接使用AbpSession属性。

2.2.3 使用会话属性

AbpSession定义的一些关键属性：

• UserId： 当前用户的标识ID，如果没有当前用户则为null。如果调用的代码是已授权，那么它不可能为空。

• TenantId： 当前租户的标识ID，如果没有当前租户则为null(如果用户没有登录或者他是一个Host用户)。

• ImpersonatorUserId： 模拟用户的标识ID，如果当前会话被其他用户模拟登录。如果不是一个模拟登录，那么该值为空。

• ImpersonatorTenantId： 模拟用户租户的标识ID，如果当前会话被其他用户模拟登录。如果不是一个模拟登录，那么该值为空。

• MultiTenancySide： 可能是Host或Tenant。

UserId和TenantId是可空类型。当然也提供了不为空时获取数据的 GetUserId() 和 GetTenantId() 方法 。当你确定有当前用户时，你可以使用GetUserId()方法。

如果当前用户为空，使用该方法则会抛出一个异常。GetTenantId()的使用方式和GetUserId()类似。

模拟属性不像其它通用属性一样用于审计日志。

2.2.4 User Identifier

你可以使用 ToUserIdentifier() 扩展方法从IAbpSession创建一个UserIdentifier对象。因为UserIdentifier被大多数API使用，所以使用该方法可以很方便的为当前用户创建一个UserIdentifier。

2.3 ABP公共结构 - 缓存管理

2.3.1 简介

ABP给出了一个抽象缓存基类。并在内部使用了该抽象基类。使用 MemoryCache.aspx?f=255&MSPPError=-2147217396) 来实现了该抽象基类。它能够被任何其它的缓存类来扩展。Abp.RedisCache 包就扩展了该缓存基类。

2.3.2 ICacheMananger

ABP对外提供了一个缓存接口ICacheMananger。我们通过构造函数注入这个接口来获取缓存。示例如下：

public class TestAppService : ApplicationService
{
    private readonly ICacheManager _cacheManager;
    public TestAppService(ICacheManager cacheManager)
    {
        _cacheManager = cacheManager;
    }
    public Item GetItem(int id)
    {
        //取得缓存
        return _cacheManager
                .GetCache("MyCache")
                .Get(id.ToString(), () => GetFromDatabase(id)) as Item;
    }
    public Item GetFromDatabase(int id)
    {
        //... 从数据库中检索数据
    }
}

在这个示例中，我们注入了 ICacheManager接口，并且获取了一个名称为MyCache的缓存。缓存的名字是大小写敏感的，那就是”MyCache”和”MYCACHE”取得的缓存内容是不同的。

注意：GetCache方法 千万不要在你的构造函数中使用GetCache方法。如果类不是一个单例对象那么该缓存可能会被dispose掉。

2.3.3 ICache

ICacheManager.GetCache方法返回了一个ICache对象。每一个缓存都是基于名称单例存在的。只有首次访问时才会被创建，以后你每次用相同的名称去获取的缓存都是相同的。所以我们可以在不同的类中使用相同的名称来共享相同的缓存。

在示例代码中，我们简单的使用了ICache.Get 方法，它有两个参数：

• key : 要获取的缓存项的唯一标识符

• factory：如果根据给定的key获取到的缓存项为空，那么factory将会创建一个标识符为key的缓存，并且返回该缓存

ICache接口还有其它方法，例如：GetOrDefault，Set，Remove和Clear。当然也有这些方法的异步(async)版本。

2.3.4 ITypedCache

ICache 接口用key(字符串类型)来获取缓存value(object类型)。ITypedCache 为ICahe提供了一个 类型安全 的包装；为了使类型安全转换(ICache到ITypedCache)，我们可以用扩展方法 AsTyped，而不需要写其它强制类型转换的代码，如下所示：

ITypedCache<int, Item> myCache = _cacheManager.GetCache("MyCache").AsTyped<int, Item>();

2.3.5 Configuration

缓存的过期时间默认是60分钟。它是变化的。如果你在60分钟内没有使用该缓存，该缓存会被自动的移除。如果你想改变所有的缓存或者指定的缓存来的默认过期时间，你可以这样做，实现如下：

//对所有缓存的配置
Configuration.Caching.ConfigureAll(cache =>
{
    cache.DefaultSlidingExpireTime = TimeSpan.FromHours(2);
});
//对指定缓存的配置
Configuration.Caching.Configure("MyCache", cache =>
{
    cache.DefaultSlidingExpireTime = TimeSpan.FromHours(8);
});

这段代码你应该放在模块(module)的 PreInitialize 方法中。如上所示：MyCache将会在8小时后过期，而其他的缓存将在2小时后过期。

这些配置将会在首次创建缓存的时候生效。配置不仅仅局限于DefaultSlidingExpireTime，你可以利用ICache接口中的属性获取方法来自由的配置并且初始化它们。

2.3.6 Entity Caching

ABP的缓存系统是以通用为目的，它有一个 EntityCache 基类，如果你需要的话，这个基类可以帮助你缓存实体。使用这个基类，我们可以通过ID取得实体，并且我们通过ID来缓存实体，这样以后就不需要频繁的查询数据库去取得实体。假设我们有个Person实体，像下面一样：

public class Person : Entity
{
    public string Name { get; set; }
    public int Age { get; set; }
}

并且，假设我们通过该实体的Id，需要频繁调用取得Person实体的Name。首先，我们应该创建一个类来存储 cache items：

[AutoMapFrom(typeof(Person))]
public class PersonCacheItem
{
    public string Name { get; set; }
}

我们 不应该直接存储实体到缓存中 因为缓存的时候需要序列化缓存对象而实体可能不能被序列化(尤其是实体的导航属性)。这就是为什么我们定义了一个简单的像DTO的类来存储数据到缓存中。我们添加了 AutoMapFrom 特性，这是因为我们想使用 AutoMapper 来自动的转换 Person 实体为 PersonCacheItem 对象。如果我们不使用 AutoMapper，那么我们应该重写 EntityCache 类的 MapToCacheItem 方法手动转换/映射它。

然而这不是必须的，我们可能想定义一个接口为缓存类：

public interface IPersonCache : IEntityCache<PersonCacheItem>
{
}

最后，我们可以创建缓存类来缓存Person实体：

public class PersonCache : EntityCache<Person, PersonCacheItem>, IPersonCache, ITransientDependency
{
    public PersonCache(ICacheManager cacheManager, IRepository<Person> repository)
        : base(cacheManager, repository)
    {
    }
}

这样就OK了，我们的person缓存已经准备好可以使用了。缓存类可以使瞬时(如同这个例子)或者是单例。这不是说缓存数据是瞬态的。在你的应用程序中它一直是全局缓存并且是线程安全的。

现在，无论在什么地方我们需要取得Person的Name，我们可以通过Person的Id从缓存中取得它。如下所示：

public class MyPersonService : ITransientDependency
{
    private readonly IPersonCache _personCache;
    public MyPersonService(IPersonCache personCache)
    {
        _personCache = personCache;
    }
    public string GetPersonNameById(int id)
    {
        return _personCache[id].Name; //alternative: _personCache.Get(id).Name;
    }
}

我们很容易的注入 IPersonCache 接口，通过该接口取得缓存项和Name属性。

那么EntityCache是怎么工作的？

• 在首次调用的时候我们通过仓储从数据库中取得实体。那么随后的调用都是从缓存中取得。

• 如果实体被更新或者删除，它会自动的无效实体。因此，它会在下次调用的时候重新从数据库中检索数据。

• 使用 IObjectMapper 接口来映射实体到缓存项。IObjectMapper 接口在 AutoMapper 中被实现。所以，如果你使用了自动映射，那么就需要 AutoMapper模块。你可以重写 MapToCacheItem 方法手动映射它到缓存项。

• 使用缓存类的FullName作为缓存的Name，你可以通过传入的缓存名到基类的构造函数来改变它。

• 它是线程安全的。

如果你有更复杂的缓存需求，那么你需要扩展 EntityCache 类或者创建你自己的解决方案。

Redis Cache 集成

默认Cache Mananger是使用 in-memory 来缓存。所以，这可能会成为一个问题，如果有多个并发的Web服务运行在同一个应用中。在这种情况下，你可能想要一个分布式/中央缓存服务器。那么，你可以使用Redis来作为你的缓存服务。

首先，你需要安装 Abp.RedisCache nuget package 到你的项目中(你可以安装它到你的Web项目)。那么你需要为 AbpRedisCacheModule 添加 DependsOn 特性，并且在你模块的 PreInitialize 方法中调用 UseRedis 扩展方法，如下所示：

//...其他名称空间的引用
using Abp.Runtime.Caching.Redis;
namespace MyProject.AbpZeroTemplate.Web
{
    [DependsOn(
        //...其他依赖模块
        typeof(AbpRedisCacheModule))]
    public class MyProjectWebModule : AbpModule
    {
        public override void PreInitialize()
        {
            //...其他配置
            Configuration.Caching.UseRedis();
        }
        //...其他代码
    }
}

Abp.RedisCache package 使用 “localhost” 作为默认的 连接字符串。你可以添加连接字符串到你的配置文件中来覆盖它。如：

<add name="Abp.Redis.Cache" connectionString="localhost"/>

你也可以添加配置到appSettings来设置Redis数据库的Id。如：

<add key="Abp.Redis.Cache.DatabaseId" value="2"/>

在同一个服务器上使用不同的数据库Id是非常有用的这可以创建不同的Key Spaces(隔离缓存)。

UseRedis 有一个重载方法，你可以通过这个方法来传入配置参数，这可以覆盖掉配置文件中的配置。

关于Redis的其他配置可以查看 Redis文档。

当然译者也简单的对StackExchange.Redis进行了翻译，吐槽一下这个文档的作者可能真的是一个真正的程序员，你懂的。

注意：在ABP中使用Redis缓存你需要安装Redis服务并使其运行。

2.4 ABP公共结构 - 日志管理

2.4.1 服务器端

ABP使用Castle Windsor’s logging facility日志记录工具，并且可以使用不同的日志类库，比如：Log4Net, NLog, Serilog… 等等。对于所有的日志类库，Castle提供了一个通用的接口来实现，我们可以很方便的处理各种特殊的日志库，而且当业务需要的时候，很容易替换日志组件。

 译者注：Castle是什么?Castle是针对.NET平台的一个开源项目，从数据访问框架ORM到IOC容器，再到WEB层的MVC框架、AOP，基本包括了整个开发过程中的所有东西。ASP.NET Boilerplate的ioc容器就是通过Castle实现的。

Log4Net是asp.net下面最流行的一个日志库组件， ASP.NET Boilerplate 模板也使用了Log4Net日志库组件，但是呢，我们这里仅仅通过一行关键代码就实现Log4Net 的依赖注入（具体说明在下面的配置文件），所以，如果你想替换成自己的日志组件，也很容易。

1. 获取日志记录器(logger)

不管你选择哪一个日志库组件，通过代码来进行日志记录都是一样的。（这里吐槽， Castle’s 通用 ILogger 接口实在太牛逼了）。

下面进入正题：(注:下面的代码是abp框架的Castle.Core源码分析以及实现)

首先呢，我们要先处理日志记录器对象logger， ASP.NET Boilerplate框架使用了dependency injection依赖注入技术,我们可以很方便的使用依赖注入生成日志记录器对象logger。

接下来我们看一下 ASP.NET Boilerplate是怎么实现日志记录功能的吧：

//1: 导入日志的命名空间，Castle.Core.Logging
using Castle.Core.Logging; 
public class TaskAppService : ITaskAppService
{ 
   /*
   2:通过依赖注入获取日志记录器对象。
   这里先定义了一个ILogger类型的public属性Logger，这个对象就是我们用来记录日志的对象。在创建了TaskAppService对象（就是我们应用中定义的任务）以后，通过属性注入的方式来实现。
   */
   public ILogger Logger { get; set; }
   public TaskAppService()
   { 
      /*
      3: 如果没有日志记录器，将日志记录器返回一个空的实例，不写日志。这是依赖注入的最佳实现方式，
        如果你不定义这个空的日志记录器，当我们获取对象引用并且实例化的时候，就会产生异常。
        这么做，保证了对象不为空。所以，换句话说，不设置日志记录器，就不记录日志，返回一个null的对象。
        NullLogger对象实际上什么都木有，空的。这么做，才能保证我们定义的类在实例化时正常运作。
      */
      Logger = NullLogger.Instance;
   }
   public void CreateTask(CreateTaskInput input) 
   {
      //4: 写入日志
      Logger.Info("Creating a new task with description: " + input.Description);
      //TODO: save task to database... 
   } 
}

写入日志以后，我们可以查看日志文件，就像下面的格式：

INFO 2014-07-13 13:40:23,360 [8] SimpleTaskSystem.Tasks.TaskAppService - Creating a new task with description:Remember to drink milk before sleeping!

2. 通过基类使用日志记录(Logger)

ABP提供了MVC Controllers、Web API Controllers和Application service classes的基类（自己定义的控制器和应用服务，都必须要继承ABP的基类，换句话说，当你自定义的Web API controllers、mvc controllers，Application service classes都继承了ABP框架对应的基类，你就可以直接使用日志记录器）。

public class HomeController : SimpleTaskSystemControllerBase  
{ 
   public ActionResult Index() 
   { 
      Logger.Debug("A sample log message..."); 
      return View(); 
   } 
}

说明：SimpleTaskSystemControllerBase这个基类控制器是我们自己定义的基类控制器，他必须继承自 AbpController。

这样实现，日志记录器才能正常工作。当然了，你也可以实现自己的基类，这样的话你也可以不使用依赖注入了。

3. 配置(Configuration)

如果你在官网上通过ASP.NET Boilerplate templates 来生成了你的工程，Log4Net的所有配置都自动生成了。

默认的配置格式如下：

• Log level: 日志记录等级，有DEBUG, INFO, WARN, ERROR or FATAL5个。
• Date and time: 日志记录时间。
• Thread number: 每行日志写时候的线程号。
• Logger name: 日志记录器的名字，通常情况就是类名称。
• Log text: 你写入的日志内容。

配置文件：log4net.config 一般都在项目的web目录下面。

<?xml version="1.0" encoding="utf-8" ?>
<log4net>
  <appender name="RollingFileAppender" type="log4net.Appender.RollingFileAppender" >
    <file value="Logs/Logs.txt" />
    <appendToFile value="true" />
    <rollingStyle value="Size" />
    <maxSizeRollBackups value="10" />
    <maximumFileSize value="10000KB" />
    <staticLogFileName value="true" />
    <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%-5level %date [%-5.5thread] %-40.40logger - %message%newline" />
    </layout>
  </appender>
  <root>
    <appender-ref ref="RollingFileAppender" />
    <level value="DEBUG" />
  </root>
  <logger name="NHibernate">
    <level value="WARN" />
  </logger>
</log4net>

Log4Net是一个非常强大和易用的日志库组件，你可以写各种日志，比如写到txt文件，写入到数据库等等。你能设置最小的日志等级，就像上面这个针对NHibernate的配置。不同的记录器写不同的日志，等等。

具体的用法大家可以参照：http://logging.apache.org/log4net/release/config-examples.html

最后，在工程的Global.asax 文件中，来定义Log4Net的配置文件：

public class MvcApplication : AbpWebApplication
{
    protected override void Application_Start(object sender, EventArgs e)
    {
        IocManager.Instance.IocContainer.AddFacility<LoggingFacility>(f => f.UseLog4Net().WithConfig("log4net.config"));
        base.Application_Start(sender, e);
    }
}

几行代码就调用了Log4Net这个日志记录组件，工程中的Log4Net库是在 nuget package包中的，你也可以换成其他日志组件库，但是代码不用做任何改变。因为，我们的框架是通过依赖注入实现日志记录器的。

4. Abp.Castle.Log4Net 包

ABP使用了 Castle Logging Facility 来记录日志，正如上面所述，它不直接的依赖 log4net。在这里我们有一个关于Castle Log4Net的集成问题，它不支持最新的log4net。我们创建了一个 Abp.Castle.Log4Net 包来解决这个问题。添加这个包到你的项目后，我们应该在 Application_Start 里修改我们的代码，如下所示：

public class MvcApplication : AbpWebApplication
{
    protected override void Application_Start(object sender, EventArgs e)
    {
        IocManager.Instance.IocContainer.AddFacility<LoggingFacility>(f => f.UseAbpLog4Net().WithConfig("log4net.config"));
        base.Application_Start(sender, e);
    }
}

唯一的不同点就是我们使用的是 UseAbpLog4Net() 方法(该方法定义在 Abp.Castle.Logging.Log4Net命名空间中) 来替换之前的 UseLog4Net() 方法。当我们使用Abp.Castle.Log4Net包时，我们将再也不需要使用 Castle.Windsor-log4net 和 Castle.Core-log4net 包 。

2.4.2 客户端

最后，更厉害的是，你还可以在客户端调用日志记录器。在客户端，ABP有对应的 javascript 日志API，这意味着你可以记录下来浏览器的日志，实现代码如下：

abp.log.warn('a sample log message...');

注意：客户端javascript的api，这里要说明的是，你可以使用console.log在客户端输出日志，但是这个API 不一定支持所有的浏览器，还有可能导致你的脚本出现异常，你可以使用我们的api，我们的是安全的，你甚至可以重载或者扩展这些api。

• abp.log.debug(‘…’);
• abp.log.info(‘…’);
• abp.log.warn(‘…’);
• abp.log.error(‘…’);
• abp.log.fatal(‘…’);

2.5 ABP公共结构 - 设置管理

2.5.1 简介

每个应用程序需要存储一些设置并在应用程序的某个地方使用这些设置。ABP框架提供强大的基础架构，我们可以在服务端或者客户端设置，来存储/获取应用程序、 租户和用户级别的配置。

设置通常是存储在数据库（或另一个来源）中，用名称-值（name-value）字符串对应的结构来表示。我们可以把非字符串值转换成字符串值来存储。

注意：关于ISettingStore接口:为了使用设置管理必须实现 ISettingStore 接口。你可以用自己的方式实现它，在module-zero项目中有完整的实现可以参考。

2.5.2 定义设置

使用设置之前必须要先定义。ABP框架是模块化设计，所以不同的模块可以有不同的设置。为了定义模块自己的设置，每个模块都应该创建继承自 SettingProvider 的派生类。设置提供程序示例如下所示：

public class MySettingProvider : SettingProvider
{
    public override IEnumerable<SettingDefinition> GetSettingDefinitions(SettingDefinitionProviderContext context)
    {
        return new[]
                {
                    new SettingDefinition(
                        "SmtpServerAddress",
                        "127.0.0.1"
                        ),
                    new SettingDefinition(
                        "PassiveUsersCanNotLogin",
                        "true",
                        scopes: SettingScopes.Application | SettingScopes.Tenant
                        ),
                    new SettingDefinition(
                        "SiteColorPreference",
                        "red",
                        scopes: SettingScopes.User,
                        isVisibleToClients: true
                        )
                };
    }
}

GetSettingDefinitions 方法返回 SettingDefinition 对象。SettingDefinition 类的构造函数中有如下参数：

• Name (必填):必须具有全系统唯一的名称。比较好的办法是定义字符串常量来设置Name。

• Default value: 设置一个默认值。此值可以是null 或空字符串。

• Scopes: 定义设置的范围 (见下文)。

• Display name: 一个可本地化的字符串，用于以后在UI中显示设置的名称。

• Description: 一个可本地化的字符串，用于以后在UI中显示设置的描述。

• Group: 可用于设置组。这仅仅是UI使用，不用于设置管理。

• IsVisibleToClients: 设置为 true 将使设置在客户端可用。

• isInherited: 用于设置，如果该设置继承了tenant或者用户(参照设置范围章节)。

• customData: 可以用来设置自定义数据对于该定义的设置。

在创建设置提供程序(SettingProvider)之后，我们应该在预初始化(PreIntialize)方法中注册我们的模块:

Configuration.Settings.Providers.Add<MySettingProvider>();

设置提供程序会自动注册依赖注入。所以，设置提供程序可以注入任何依赖项 (如存储库) 来生成设置定义的一些其它来源。

2.5.3 设置范围

有三个设置范围 (或级别) 在 SettingScopes 枚举中定义:

• Application：应用程序范围设置用于用户/租户独立的设置。例如，我们可以定义一个名为”SmtpServerAddress”的设置，当发送电子邮件时，获取服务器的 IP 地址。如果此设置有一个单一的值 (不基于用户改变)，那么我们可以定义它为应用程序范围。

• Tenant：如果应用程序是多租户的，我们可以定义特定于租户的设置。

• User：我们可以使用的用户范围的设置来为每个用户存储/获取设置的值。

SettingScopes 枚举具有Flags属性，所以我们可以定义一个具有多个作用域的设置。

设置范围是分层的。例如，如果我们定义设置范围为”Application | Tenant | User”并尝试获取当前设置的值;

我们获取特定用户的值，如果它定义了 (重写) User;如果没有定义User，我们获取特定的租户值，如果它定义了 (重写) Tenant。如果也没有，我们获取应用的值，如果它定义了Application。如果还是没有，我们得到的默认值。

默认值可以是 null 或空字符串。如果可以，建议为设置提供一个默认值。

2.5.4 重写定义的设置

context.Manager 可以用来取得某个定义的设置并更改它的值。你可以使用这种方式来操控依赖模块的定义的设置。

2.5.5 获取设置值

定义设置后，我们可以在服务器和客户端获取到它的当前值。

1. 服务器端(Server side)

ISettingManager 用于执行设置操作。我们可以在应用程序中任何地方注入和使用它。ISettingManager 定义了很多获取设置值方法。

最常用的方法是 GetSettingValue (或GetSettingValueAsync 为异步调用)。它将返回当前设置的基于默认值、 应用程序、 租户和用户设置范围的值(如设置范围之前的一段中所述)。例子:

//Getting a boolean value (async call)
var value1 = await SettingManager.GetSettingValueAsync<bool>("PassiveUsersCanNotLogin");
//Getting a string value (sync call)
var value2 = SettingManager.GetSettingValue("SmtpServerAddress");

GetSettingValue 有泛型和异步版本，如上所示。也有方法来获取特定的租户或用户的设置值或所有设置值的列表。

由于ISettingManager使用广泛，一些特定的基类 (如 ApplicationService、 DomainService 和 AbpController) 有一个名为 SettingManager的属性。如果我们从这些类继承，就无需显式地注入它。

2. 客户端(Client side)

如果定义设置时将 IsVisibleToClients 设置为 true，就可以在客户端使用 javascript得到它的当前值。abp.setting 命名空间定义所需的函数和对象。示例:

var currentColor = abp.setting.get("SiteColorPreference");

也有 getInt 和 getBoolean 这样的方法。你可以使用 abp.setting.values 对象获取所有值。请注意，如果你在服务器端更改设置，客户端不会知道这种变化，除非刷新页面或者以某种方式重新加载页面或者通过代码手动更新。

3. 更改设置

ISettingManager定义了ChangeSettingForApplicationAsync，ChangeSettingForTenantAsync 和 ChangeSettingForUserAsync 方法（以及同步版本）来更改应用程序，租户和用户分别的设置。

4. 关于缓存

缓存在服务器端设置管理，所以，我们不应直接使用存储库或数据库更新语句改变设置的值。

（2.1、2.2由半冷翻译，2.3由天道翻译，2.4由李伟翻译）

2.6 ABP公共结构 - 时间与时区设置

2.6.1 简介

虽然有些应用的需求是单时区，然而另一些是需要对不同的时区进行处理的。为了满足这样的需求以及对时间的处理。ABP提供了处理时间操作的通用基础设施。

2.6.2 Clock

Clock 这个类是主要用来处理 DateTime 的值。它具有以下静态属性和方法：

• Now ：根据当前设置的提供器来获取当前时间

• Kind ：取得当前提供器的 DateTimeKind

• SupportsMultipleTimezone ：取得一个值用来判断该应用当前所使用的提供器是否支持多时区转换(只有ClockProviders.Utc才支持多时区之间的转换)

• Normalize 对给定的时间使用当前提供器来进行转换

所以我们不应该使用 DateTime.Now，而是使用 Clock.Now，如下所示：

DateTime now = Clock.Now;

ABP中内置了3种Provider，如下所示：

• ClockProviders.Unspecified (UnspecifiedClockProvider)：这是默认的provider并且它的表现行为就像 DateTime.Now。

• ClockProviders.Utc (UtcClockProvider): 它使用UTC时间，Clock.Now 等效于 DateTime.UtcNow。Normalize方法会将给定的时间转换为UTC时间并且设置它的Kind为 DateTimeKind.Utc。它支持多时区操作。

• ClockProviders.Local (LocalClockProvider): 程序宿主的计算机时间。Normalize方法会将给定的时间转换为本地时间并且设置它的Kind为 DateTimeKind.Local。

为了支持多时区转换，你可以设置Clock.Provider为：

Clock.Provider = ClockProviders.Utc;

对于上面的设置，我们通常是在应用程序主入口就设置好了。例如：main函数，web应用的Application_Start函数。

2.6.3 Client Side

我们可以在客户端脚本中使用 abp.clock， 当你在服务器端设置好 Clock.Provider，ABP 会自动的在客户端设置好 abp.clockprovider。ABP创建了一个脚本对象：abp.timing.timeZoneInfo 它包含了当前用户所设置的时区信息。这个信息包含了Windows和IANA时区的id和一些额外的windows时区信息，详细请查看源码 TimingScriptManager 的GetUsersTimezoneScriptsAsync函数。使用这些信息可以将服务器的UTC时间转换为客户端需要显示的时间。

注意：在客户端进行时间转换，首先你得设置你的应用默认为Utc，并且每个用户可以设置自己的时区，这个默认是使用SettingManager来设置的。然后你可以使用monent的timezone插件将服务器端时间转换为本地时间。首先全局设置：moment.tz.setDefault(abp.timing.timeZoneInfo.iana.timeZoneId); 然后你通过动态API，或者WebAPI取得JSON后，将JSON中的时间如此转换： moment(item.creationTime).format(‘LLL’)，或者可以这样： abp.timing.convertToUserTimezone(dateTime).format(); 前提是你要使用abp.moment.js。作者的文档写的也不是很好，这是我开发过程中结合源码补充的。如果要为每个用户设置不同的时区，最好是将时区信息保存到用户表，登录的时候保存到Claim中。那么在MVC中转换的时候我们就可以用到 TimezoneHelper.ConvertFromUtc 。详细可以见提问：https://github.com/aspnetboilerplate/aspnetboilerplate/issues/1320。

如果使用用户表来保存每个用户的时区，最好是自定义一个AbpSession：

    public interface ICustomAbpSession : IAbpSession
    {
        string TimezoneId { get; }
        string ImpersonatorTimezoneId { get; }
        string GetUsersTimezoneScript();
    }
    public class CustomAbpSession : ClaimsAbpSession, ICustomAbpSession
    {
        public CustomAbpSession(IMultiTenancyConfig multiTenancy) : base(multiTenancy)
        {
        }
        public virtual string TimezoneId
        {
            get
            {
                var timezoneIdClaim = PrincipalAccessor.Principal?.Claims.FirstOrDefault(c => c.Type == CustomAbpClaimTypes.TimezoneId);
                return string.IsNullOrEmpty(timezoneIdClaim?.Value) ? null : timezoneIdClaim.Value;
            }
        }
        public virtual string ImpersonatorTimezoneId
        {
            get
            {
                var impersonatorTimezoneIdClaim = PrincipalAccessor.Principal?.Claims.FirstOrDefault(c => c.Type == CustomAbpClaimTypes.ImpersonatorTimezoneId);
                return string.IsNullOrEmpty(impersonatorTimezoneIdClaim?.Value) ? null : impersonatorTimezoneIdClaim.Value;
            }
        }
        //使用这个代码来重置 TimingScriptManager.cs 的GetUsersTimezoneScriptsAsync函数取得的脚本。
        //当然需要在_Layout.cshtml 中调用这个方法，如果不想这样写，也可以继承ITimingScriptManager接口，重新实现它。
        public virtual string GetUsersTimezoneScript()
        {
            if (!Clock.SupportsMultipleTimezone)
                return string.Empty;
            var timezoneId = TimezoneId;
            var timezone = TimeZoneInfo.FindSystemTimeZoneById(timezoneId);          
            var timezoneInfo = " {" +
                                  "        windows: {" +
                                  "            timeZoneId: '" + timezoneId + "'," +
                                  "            baseUtcOffsetInMilliseconds: '" + timezone.BaseUtcOffset.TotalMilliseconds + "'," +
                                  "            currentUtcOffsetInMilliseconds: '" + timezone.GetUtcOffset(Clock.Now).TotalMilliseconds + "'," +
                                  "            isDaylightSavingTimeNow: '" + timezone.IsDaylightSavingTime(Clock.Now) + "'" +
                                  "        }," +
                                  "        iana: {" +
                                  "            timeZoneId:'" + TimezoneHelper.WindowsToIana(timezoneId) + "'" +
                                  "        }," +
                                  "    }";
            return " abp.timing.timeZoneInfo = " + timezoneInfo;
        }
    }

2.6.4 时区

ABP定义了一个 Abp.Timing.TimeZone 配置名，用来存储Host，Tenant和User所选择的时区。ABP假定设定的时区是一个有效的 Windows timezone id。ABP也定义了一个时区映射文件，将Windows时区转换为 IANA 时区，这是因为有些通用库所使用的是 IANA timezone id。为了支持多时区，必须使用 UtcClockProvider。如果使用 UtcClockProvider，那么所有的时间值将会以UTC时间进行存储，并且以UTC时间发送到客户端。那么在客户端我们能将UTC时间转换为客户所设置的时区。

注意: 我遇到过这样的问题，在Windows Server 2012 如果系统的时区是协调世界时(Coordinated Universal Time)。并且默认用户时区是系统时区时，TimeZoneInfo.FindSystemTimeZoneById(timezoneId)，ABP中取得IANA时区会报异常。

2.6.5 Binders and Converters

• ABP能自动normalize来自如MVC，WebAPI以及ASP.NET Core应用的时间，这是基于当前的ClockProvider的。

• ABP能基于当前的ClockProvider自动normalize来自数据库的时间，当 EntityFramework 以及 NHibernate 模块被使用的时候。

如果 UtcClockProvider 被使用，所有的时间都会作为UTC时间存储在数据库。并且所有来自客户端的时间都会被当做UTC时间来接收除非被明确的指定为其他时区。

2.7 ABP公共结构 - 对象之间的映射

2.7.1 简介

我们通常需要在近似的对象之间进行映射处理。这是一个重复且枯燥无味的工作，通常来说两个需要相互映射的对象之间有近似的或者相同的属性。思考一下这样一个案例：应用服务的方法：

public class UserAppService : ApplicationService
{
    private readonly IRepository<User> _userRepository;
    public UserAppService(IRepository<User> userRepository)
    {
        _userRepository = userRepository;
    }
    public void CreateUser(CreateUserInput input)
    {
        var user = new User
        {
            Name = input.Name,
            Surname = input.Surname,
            EmailAddress = input.EmailAddress,
            Password = input.Password
        };
        _userRepository.Insert(user);
    }
}

在这里，User是一个简单的实体；CreateUserInput是一个简单的DTO。从给定的输入对象，我们需要使用它来创建一个User实体。在真实的环境中User实体会有更多的属性，手动创建这个实体会变得枯燥无味且易出错。如果我们想要添加新的属性到User和CreateUserInput的时候，这会变得很复杂，我们应该改变这个映射代码，使映射更简单。

我们可以使用一个类库来实现自动映射。AutoMapper是最好的处理对象到对象之间映射的类库之一。ABP中定义了 IObjectMapper 接口，抽象了映射功能。在Abp.AutoMapper包中，我们实现了该接口来使用AutoMapper。

2.7.2 IObjectMapper 接口

IObjectMapper简单的抽象出了对象到对象之间映射的方法。我们可以使用更简单的代码实现上面提到的映射功能：

public class UserAppService : ApplicationService
{
    private readonly IRepository<User> _userRepository;
    private readonly IObjectMapper _objectMapper;
    public UserAppService(IRepository<User> userRepository, IObjectMapper objectMapper)
    {
        _userRepository = userRepository;
        _objectMapper = objectMapper;
    }
    public void CreateUser(CreateUserInput input)
    {
        var user = _objectMapper.Map<User>(input);
        _userRepository.Insert(user);
    }
}

Map 是一个简单的具有类型声明的泛型占位符的方法，可以将一个对象映射为另一个对象。Map方法的重载方法可以映射一个对象到一个 已存在 的对象。假设我们有了一个User实体，但是我们想通过DTO来更新用户实体的某些属性：

public void UpdateUser(UpdateUserInput input)
{
    var user = _userRepository.Get(input.Id);
    _objectMapper.Map(input, user);
}

2.7.3 AutoMapper 集成

在Abp.AutoMapper包中，我们实现了IObjectMapper接口并提供了一些辅助功能。

安装

首先，需要安装 Abp.AutoMapper 到你的项目中：

Install-Package Abp.AutoMapper

然后添加 AbpAutoMapperModule 作为依赖项到你定义的模块类中：

[DependsOn(typeof(AbpAutoMapperModule))]
public class MyModule : AbpModule
{
    ...
}

这样你就可以在代码中安全的注入和使用IObjectMapper接口了。如果有需要，你也可以使用AutoMapper自己的API。

创建映射

在使用映射之前，AutoMapper默认需要定义类之间的映射关系。在使用的时候你可以查询它的文档。但是使用ABP会使映射关系的创建更简单且模块化。

自动映射特性

大多数时候你只想对类进行直接(按约定的方式)映射。在这种情况下，你可以使用 AutoMap，AutoMapFrom 以及 AutoMapTo 特性。例如：在上面的例子中，我们将 CreateUserInput 映射到 User，我们可以使用 AutoMapTo 特性来实现。如下所示：

[AutoMapTo(typeof(User))]
public class CreateUserInput
{
    public string Name { get; set; }
    public string Surname { get; set; }
    public string EmailAddress { get; set; }
    public string Password { get; set; }
}

AutoMap特性可以在两个类型之间实现彼此之间的相互映射。但是在这个例子中，我们只需要将 CreateUserInput 映射到 User。所以我们可以使用 AutoMapTo。

自定义映射

在某些情况下，简单的映射不能满足需求。例如：两个类中的属性名字可能稍微有些不同或者你想忽略某些属性的映射。在这种情况下，你可以直接使用 AutoMapper 的 API 来实现映射。Abp.AutoMapper 包中的定义的 API 使自定义映射更加模块化。

假设在映射的时候，我们想忽略Password属性，并使 EmailAddress 属性映射到 User 的Email 属性。我们可以像下面一样来实现映射关系：

[DependsOn(typeof(AbpAutoMapperModule))]
public class MyModule : AbpModule
{
    public override void PreInitialize()
    {
        Configuration.Modules.AbpAutoMapper().Configurators.Add(config =>
        {
            config.CreateMap<CreateUserInput, User>()
                  .ForMember(u => u.Password, options => options.Ignore())
                  .ForMember(u => u.Email, options => options.MapFrom(input => input.EmailAddress));
        });
    }
}

AutoMapper拥有更多的选项和能力来做对象之间的映射。详情请查询文档。

MapTo扩展方法

如上面所述，我们建议注入并使用IObjectMapper接口。这使我们的项目尽可能的不依赖AutoMapper。这也使单元测试更简单，因为在单元测试的时候我们可以替换掉映射依赖。

在 Abp.AutoMapper 中也有 MapTo 的扩展方法，我们可以不注入IObjectMapper接口，使用它将任意对象映射为其它对象。如下所示：

public class UserAppService : ApplicationService
{
    private readonly IRepository<User> _userRepository;
    public UserAppService(IRepository<User> userRepository)
    {
        _userRepository = userRepository;
    }
    public void CreateUser(CreateUserInput input)
    {
        var user = input.MapTo<User>();
        _userRepository.Insert(user);
    }
    public void UpdateUser(UpdateUserInput input)
    {
        var user = _userRepository.Get(input.Id);
        input.MapTo(user);
    }
}