ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统

ABP+AdminLTE+Bootstrap Table权限管理系统一期
Github:https://github.com/Jimmey-Jiang/ABP-ASP.NET-Boilerplate-Project-CMS
前往博客园总目录:ABP+AdminLTE+Bootstrap Table权限管理系统一期

说了这么久,还没有详细说到abp框架,abp其实基于DDD(领域驱动设计)原则的细看分层如下:

ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统_第1张图片

再看我们项目解决方案如下:

ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统_第2张图片

应用层(Application)：应用层:进行展现层与领域层之间的协调，协调业务对象来执行特定的应用程序的任务。它不包含业务逻辑,主要包含一些模型,abp重要的数据传输DTO,包括数据库映射实体,前端视图模型转实体(Entity)对象,一个应用服务方法通常被认为是一个工作单元（Unit of Work）,使用一种像AutoMapper这样的工具来进行实体与DTO之间的映射,前端参数传入有限性验证等等
领域层(Domain)：领域层:领域层就是业务层，是一个项目的核心，所有业务规则都应该在领域层实现。包括业务对象和业务规则，这是应用程序的核心层。

实体（Entity）:实体代表业务领域的数据和操作，在实践中，通过用来映射成数据库表。
仓储（Repository）:仓储用来操作数据库进行数据存取。仓储接口在领域层定义，而仓储的实现类应该写在基础设施层。
领域服务（Domain service）:当处理的业务规则跨越两个（及以上）实体时，应该写在领域服务方法里面。
领域事件（Domain Event）:　在领域层某些特定情况发生时可以触发领域事件，并且在相应地方捕获并处理它们。
工作单元（Unit of Work）：工作单元是一种设计模式，用于维护一个由已经被修改(如增加、删除和更新等)的业务对象组成的列表。它负责协调这些业务对象的持久化工作及并发问题。****

基础设施层(Infrastructure)：基础设施层:提供通用技术来支持更高的层。例如基础设施层的仓储(Repository)可通过ORM来实现数据库交互。当在领域层中为定义了仓储接口，应该在基础设施层中实现这些接口。可以使用ORM工具，例如EntityFramework或NHibernate。ABP的基类已经提供了对这两种ORM工具的支持。还有数据迁移等。
展现层(Presentation):**展现层:提供试图用于与用户实现交互操作.

JCmsErp.WebApi:这里在abp中主要是提供接口,可以是解决方案内部使用接口,可以是与移动端等其他端口连接的接口.

二，实体（Entity）
实体是DDD（领域驱动设计）的核心概念之一。Eirc Evans是这样描述的实体的：“它根本上不是通过属性定义的，而是通过一系列连续性和标识定义的”。因此，实体都有Id属性并且都存储到数据库中。一个实体一般会映射到数据库的一张表
abp中实体是派生于Entity类，先看一下我们在Core层新建的Users类

ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统_第3张图片

Users实体类，有人说这个实体为什么没有id,因为Users继承自Entity类，Entity类已经定义id，
它是该Entity类的主键。因此，所有实体的主键名都是相同的，都是Id。
Id（主键）的类型是可以改变的，默认是int(int32)的。如果你想将Id定义为其他类型，可以在<>内写,比如Guid,long也是可以的。
Entity类重写了等号运算符（==），可以轻松地检查两个实体是否相同了（实体的Id相同则认为它们相同）。它也定义了IsTransient方法来检测它是否有Id。

ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统_第4张图片

审计：

IHasCreationTime使得使用一个通用的属性来描述一个实体的“创建时间”信息成为可能。当实现了该接口的实体类插入到数据库中时，ABP会自动地将当前的时间设置给CreationTime。
ICreationAudited增加了CreatorUserId扩展了IHasCreationTime，当用户保存一个新的实体的时候，会自动把当前的id设置为CreatorUserId，还有类似的LastModificationTime也是一样。

当更新实体时，abp会自动为你设置这些属性。
软删除
软删除是将一个实体标记为已删除的通常使用的模式，而不是直接从数据库中删除。比如，你可能不想从数据库中硬删除一个User，因为它可能关联其他的表
ABP实现了开箱即用的软删除模式。当一个软删除实体被删除后，ABP检测到之后，会阻止删除，将IsDeleted设置为true并更新数据库中的实体。而且，它会自动地过滤数据库中软删除的实体，不会检索（select）它们。
如果使用了软删除，那么你可能想存储一些信息，比如何时删除以及谁删除了一个实体等等

ABP+AdminLTE+Bootstrap Table权限管理系统第三节--abp分层体系及ABP模块系统_第5张图片

在JCmsErp.Application创建一个Users文件夹,然后创建UserinfoDto,DTO是用于Core和 Web间的数据传输对象.有了实体了为什么还要DTO呢

DTO保证了层与层的分离,web层改变不影响core层,core做改变也不影响web.
数据保护,不然敏感或者不需要的数据暴露于web层,不被别人窥见如密码,银行账号,身份证等敏感信息
序列化,序列化集合,但是子集不序列化,当首次用到子集的时候才序列化.
惰性加载
DTO数据验证
abp还有一些扩展的接口,扩展性好,降低耦合度,使表现层和逻辑层之间耦合度降低.

这里Serializable就是支持序列化的标签, [AutoMapFrom(typeof(Users))]是指和Users之间双向自动转化的标签,并不需要每个字段都去手动匹配.ABP提供了若干特性和扩展方法来定义映射。首先，要将Abp.AutoMapper nuget包添加到项目中。然后，AutoMap特性是双向映射方式， AutoMapFrom和 AutoMapTo是单向映射方式。最后，使用MapTo扩展方法将一个对象映射到另一个对象

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之前初始化，模块启动的方法顺序如下：

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 接口的类。FolderPlugInSource 类实现了该接口，它可以被用来加载指定文件夹下的程序集。

ASP.NET Core

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

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

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

services.AddAbp(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
{
    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
    {
    }

    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 模块生命周期

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

返回总目录:ABP+AdminLTE+Bootstrap Table权限管理系统一期
前往博客园总目录:ABP+AdminLTE+Bootstrap Table权限管理系统一期