.net core ef批量修改_以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 _repository;        public BookAppService(IRepository repository)            : base(repository)        {            _repository = repository;        }  }

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

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

6、实体层的设计解析

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

在Blog.Core中，我用Model层，来封装了实体层，这个是没问题的，但是有一个问题就是，这层不应该在定义ViewModels层了，这个不应该写到这里，应该写到应用契约层，毕竟我们知道契约就是为了用户的。

在Abp框架中，设计的就比较合理了，详细你也应该能看的懂，这里不多说了。

这里要重点说的就是，领域层第二块内容——实体，刚刚我们说了第一个是仓储接口，这两个其实都是拥有领域行为的类。

7、公共层设计解析

公共层其实这个最容易理解，就是平时我们整个项目中，都会遇到的以下模块，比如错误码，本地化，枚举，常量等等，这些统一定义好后，可以贯穿到我们整个项目中。

在Blog.Core中，我就直接叫做Common层了，言简意赅。

而在Abp中，他把这些数据放到了.Domain.Shared层了，从名字可以看懂，就是分享的意思，再加上Abp是一个DDD领域驱动的框架，所以就基于领域层下的分享层了。

8、其他层设计分析

至于其他层就很简单了，Abp中，剩下的就是迁移层了：

.DbMigrator其实是一个控制台层，配置好数据库连接字符串，就可以直接生成项目了。

.EntityFrameworkCore.DbMigrations是一个类库，存放我们的迁移记录。

Blog.Core中的两个：

.FrameWork是一个T4模板，生成整个框架文件；

.Tasks是一个任务调度层，目前用的是Quartz.Net；

当然，如果你还没用过Abp，这里我列举了十步走，你可以试试。

9、Abp开发十步走

其实说了这么多，已经基本的说完了，从上边的解析中，我们可以看到，如果你学会了Blog.Core，其实很好入门Abp的，至少我只看了半个小时就知道如何开发了，这里我还列举了Abp开发十步走：

好啦，说了这么多，详细你肯定已经会使用Abp了吧，至少写个增删改查是没问题的。