以Blog.Core的方式来打开Abp.vNext

（发现Abp这个logo真像佐助写轮眼）

最近自己的框架已经基本的成型了，当然还有很多质疑的地方，比如这些人是这么说的，基本都是原文：

你的教程太乱了，和框架代码都不一样（？？？）

文章还行，代码规范要改善（？？？）

为啥要分那么多层，看着不舒服（？？？）

给我讲讲SqlSugar的优势在哪里（？？？）

多库，读写分离没看出来有啥意义（？？？）

我也没办法，只能用问号来表示我的看法了，其实一直以来我都是希望通过文章的形式让大家如何去学习，后来虽然框架的越推越广，导致很多人都是直接通过框架来学习知识点了，所以冲突就慢慢出来了，既然本末倒置了，那索性我也倒过来，不去修改文章了，精修代码吧，因此我也打算趁着上班之余，看看传说中的最厉害，最丰富，最难懂的框架 —— Abp vNext，看看他们是如何运营的吧。

群主的安排是什么？

我的计划：很多小伙伴会说，会不会开系列教程，这个应该会有，目前我还在学习阶段，我的想法通过博客和视频的形式，来一个三步走，先了解这个框架，再使用框架搭建自己项目，最后分析下他的运行原理。

你的计划：当然这个教程肯定有范围的，初学者不建议学，建议刚入门的还是看我的教程和代码吧，然后按照这个顺序学，先掌握ASP.NET Core，然后简单了解前后端分离，再学习下DDD领域驱动设计的思想，接着简单了解下IdentityServer4的内容，至少要了解认证和授权的部分内容，我的教程目录，设计模式是辅助：

（老张的哲学，博客园系列教程）

大概就是这样，今天呢，特别简单，不会说这个框架的由来，官网地址，如何下载，如何说这个框架是多么多么厉害，大家能看到这里，证明都是知道的，今天毕竟是一个尝鲜，是先让大家初见下Abp的框架布局情况，而且是通过Blog.Core框架的形式来了解，前提是你正在使用或者研究Blog.Core。

1、两个框架的对比

既然要对比呢，我就简单的做了一个图，当然，我也不是真心的要和Abp比较，因为完全没有对比性，只是想说明一下，Abp这个框架的好处：

（Blog.Core与Abp框架对比图）

我自己简单的总结了下，Abp各个方面都很领先，是毋庸置疑的好框架，当然为了体现文章的意义，我也列举了不足之处，就是对新手的不太友好，很多初学者是看不懂的，这也就是为什么我在文章开头说的，如果想要学好Abp，可以先看看我的框架或者系列文章。

那我接下来就带着大家看看，如何通过Blog.Core来入门Abp vNext框架。

2、整体分层情况

（很巧，都是标准的十层结构）

当然，这是开玩笑的。不过总体上来看，似乎两个框架关联性并不是很大，

Blog.Core采用的是，{服务-仓储-接口}的开发模式；

Abp采用的是，{应用-领域-基础设施}的DDD开发模式；

很多人都说Blog.Core就是一个简单的三层架构，其实我当时这么写，就是为了引出后边的DDD领域驱动设计教程，不然为啥不直接叫DAL层和BLL层，还不能抬杠，抬杠我就会被问区别，我也是懒得解释。

这么看其实关联性不大，但是接下来我会拆分来讲，你就会发现，其实很多都是一样的。

3、Web层对比分析

因为默认创建的Abp框架，用的是MVC Page模式（当然它封装了api，这个以后再说），所以我们简单看一下Startup.cs就行：

Blog.Core在依赖注入中，采用的是服务模块化注册，然后配置Autofac进行服务层的依赖注入自动化，然后配套进行动态代理AOP。

Abp也是采用的模块化的注册方式，当然他这个封装的更彻底，更好吧，然后他自己也将Autofac容器给封装了，反正就是全部封装了。

4、服务层设计分析

服务层，也可以叫做应用层，主要是用来向上对展示层提供服务的，向下嘛，可以是领域层或者仓储层：

在Blog.Core中，采用的是Service和IService的形式，分了两个层，分别是

.Services 和 .IServices

我们可以定义多个服务和服务接口，来实现不同业务模块的联系，然后将IService给暴漏出给展示层。

而在Abp中呢，我们的Service层变成了应用层.Application，IServices层变成了应用契约层

.Application.Contracts，契约也就是接口，主要是对展示层进行服务封装的，然后由应用层进行实现。

除了这个服务接口呢，还有一个实体映射，也就是Dto：

在Blog.Core项目中，我设计到了Web层，当然这个也是可以的：

不过Abp倒是分开了两个部分，他在Abp和应用层都有，不过基本都是在应用层来设计的：

PS：Abp分层名字写的还是挺好的，把这两个层并列在一起了，不像我的，因为名字排序的问题，距离比较远。

5、仓储层设计解析

仓储层其实属于基础设施层的一部分，基础设施层分两部分，一个是对持久化的处理，另一个就是对公共层的封装，那现在咱们先说下第一部分，持久化：

在Blog.Core中，我单独建立了两个层，仓储和仓储接口，这个和服务层与服务接口层似乎有些雷同，很多人表示不解，为啥要分开，这里不多说，详细如果你看过DDD，明白了应用层和基础设施层的设计应该就明白了。

但是在Abp框架中，有一些不太一样了，你似乎看不到他定义Repository和IRepository的相关存在，他因为用到了EFCore，所以把EFCore当成了仓储了。

其实不是的，如果你看他的源码，就可以发现，他还是有仓储的影子的，只不过是封装了：

刚刚我们在应用层中定义的服务，其实是集成了仓储接口的，只不过是基类，而且命名空间还是Domain领域层：

    public class BookAppService :CrudAppService<Book, BookDto, Guid, PagedAndSortedResultRequestDto,CreateUpdateBookDto, CreateUpdateBookDto>,IBookAppService{private readonly IRepository<Book, Guid> _repository;public BookAppService(IRepository<Book, Guid> repository): base(repository){_repository = repository;}}

从这里我们可以看出来，领域层中定义了仓储接口，然后再在.EntityFrameworkCore层中设计我们的持久化操作。

这里就引出了第一个重要知识点，领域层中到底是什么？—— 一切包含领域行为的类，都应该封装到领域层中，目前的第一个，仓储接口。那是不是还有其他的呢？

6、实体层的设计解析

实体层这个顾名思义，我们要持久化，肯定要定义实体，或者用DDD中的属于，可以叫聚合。