Asp-Net-Core开发笔记:快速在已有项目中引入EFCore

asp,net,core,开发,笔记,快速,已有,项目,引入,efcore · 浏览次数 : 35

小编点评

**StarBlog 项目的 EFCore 整合** **简介** StarBlog 是一个 .NET6 的博客平台,目前使用的是 FreeSQL 数据库。为了支持多个数据库,例如 FreeSQL、Chláš和 PostgreSQL,StarBlog 可以使用 EFCore 来管理数据库连接。 **安装** 为了使用 EFCore 管理多个数据库,需要安装以下工具: - Microsoft.EntityFrameworkCore - Microsoft.EntityFrameworkCore.Sqlite **配置数据库** 在 StarBlog.Data 项目下,创建一个 `VisitRecordConfig.cs` 文件配置数据库连接。例如: ```csharp public class VisitRecordConfig : IEntityTypeConfiguration<VisitRecord> { public void Configure(EntityTypeBuilder<VisitRecord> builder) { builder.ToTable("visit_record"); builder.HasKey(e => e.Id); // ...其他配置 ... } } ``` **创建 DbContext 类** 创建一个 `AppDbContext` 类继承 `DbContext` 类。 DbContext 是一个与数据库交互的接口,用于执行数据库操作。 ```csharp public class AppDbContext : DbContext { public DbSet VisitRecords { get; set; } } ``` **创建 DesignTime 配置** 创建一个 `AppDesignTimeDbContextFactory.cs` 文件,用于创建设计时上下文。 ```csharp public class AppDesignTimeDbContextFactory : IDesignTimeDbContextFactory { public AppDbContext CreateDbContext(string[] args) { var builder = new DbContextOptionsBuilder<AppDbContext>(); // 连接字符串从环境变量中读取 builder.UseSqlite(builder.Configuration.GetConnectionString("SQLite-Log")); return new AppDbContext(builder.Options); } } ``` **使用 EFCore 管理数据库** 在 `Program.cs` 中注册数据库连接并创建 DbContext 实例。 ```csharp // 在 Program.cs 中注册数据库连接并创建 DbContext 实例 builder.Services.AddDbContext(options => { options.UseSqlite(builder.Configuration.GetConnectionString("SQLite-Log")); }); ``` **运行** 运行项目,会在 `StarBlog.Data` 目录下创建一个 SQLite 数据库文件。 ``` dotnet ef database update ``` **总结** 通过使用 EFCore,StarBlog 可以轻松地管理多个数据库,从而提高应用程序的性能和可扩展性。

正文

前言

很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。

本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是 FreeSQL 的话,服务注册的时候是单例模式,只能连接一个数据库,如果需要使用 FreeSQL 同时连接多个数据库,需要自行做一些额外的工作。

要实现的效果是:把访问记录单独使用一个数据库来存储,并且使用 EFCore 管理。

安装工具

首先安装 EFCore 的 cli 工具

dotnet tool install --global dotnet-ef

项目架构

先来回顾一下项目架构:基于.NetCore开发博客项目 StarBlog - (2) 环境准备和创建项目

StarBlog
├── StarBlog.Contrib
├── StarBlog.Data
├── StarBlog.Migrate
├── StarBlog.Web
└── StarBlog.sln

为了解耦,和数据有关的代码在 StarBlog.Data 项目下,因此引入 EFCore 只需要在 StarBlog.Data 这个项目中添加依赖即可。

添加依赖

StarBlog.Data 项目中添加以下三个依赖

  • Microsoft.EntityFrameworkCore
  • Microsoft.EntityFrameworkCore.Sqlite
  • Microsoft.EntityFrameworkCore.Tools

EFCore 对 SQLite 的支持很弱(根本原因是微软提供的 SQLite 驱动功能太少),所以只适合在本地开发玩玩,实际部署还是得切换成 C/S 架构的数据库(PgSQL/MySQL/SQL Server)才行。

添加后项目的 .csproj 文件新增的依赖类似这样

<PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.18" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="6.0.18" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.18">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

目前 StarBlog 还在使用 .Net6 所以我添加的 EFCore 是 6.x 版本,等后续 .Net8 正式版发布之后,我会把这个项目升级到 .Net8

创建 DbContext

DbContext 是 EFCore 与数据库交互的入口,一般一个数据库对应一个。

现在来 StarBlog.Data 项目下创建一个。

using Microsoft.EntityFrameworkCore;
using StarBlog.Data.Models;

namespace StarBlog.Data;

public class AppDbContext : DbContext {
  public DbSet<VisitRecord> VisitRecords { get; set; }
  
  public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
}

因为只需要让 EFCore 管理访问记录,所以只需要一个 DbSet

实体类配置

然后来创建个配置,虽然也可以用 Data Annotation 来配置,但 EFCore 推荐使用 Fluent Config 方式来配置数据表和字段。

创建 StarBlog.Data/Config/VisitRecordConfig.cs 文件

public class VisitRecordConfig : IEntityTypeConfiguration<VisitRecord> {
  public void Configure(EntityTypeBuilder<VisitRecord> builder) {
    builder.ToTable("visit_record");
    builder.HasKey(e => e.Id);
    builder.Property(e => e.Ip).HasMaxLength(64);
    builder.Property(e => e.RequestPath).HasMaxLength(2048);
    builder.Property(e => e.RequestQueryString).HasMaxLength(2048);
    builder.Property(e => e.RequestMethod).HasMaxLength(10);
    builder.Property(e => e.UserAgent).HasMaxLength(1024);
  }
}

主要是配置了主键和各个字段的长度。

数据类型这块 EFCore 会自动映射,具体请参考官方文档。

主键类型选择

这里插播一下题外话,关于主键类型应该如何选择。

目前主要有几种方式:

  • 自增
  • GUID
  • 自增+GUID
  • Hi/Lo

这几种方式各有优劣。

  • 自增的好处是简单,缺点是在数据库迁移或者分布式系统中容易出问题,而且高并发时插入性能较差。
  • GUID好处也是简单方便,而且也适用于分布式系统;MySQL的InnoDB引擎强制主键使用聚集索引,导致新插入的每条数据都要经历查找合适插入位置的过程,在数据量大的时候插入性能很差。
  • 自增+GUID是把自增字段作为物理主键,GUID作为逻辑主键,可以在一定程度上解决上述两种方式的问题。
  • Hi/Lo可以优化自增列的性能,但只有部分数据库支持,比如SQL Server,其他的数据库暂时还没研究。

DesignTime 配置

因为我们的项目是把 AspNetCore 和数据分离的,所以需要一个 DesignTime 配置来让 EFCore 知道如何执行迁移。

StarBlog.Data 中创建 AppDesignTimeDbContextFactory.cs 文件

public class AppDesignTimeDbContextFactory : IDesignTimeDbContextFactory<AppDbContext> {
  public AppDbContext CreateDbContext(string[] args) {
    var builder = new DbContextOptionsBuilder<AppDbContext>();

    var connStr = Environment.GetEnvironmentVariable("CONNECTION_STRING");
    if (connStr == null) {
      var dbpath = Path.Combine(Environment.CurrentDirectory, "app.log.db");
      connStr = $"Data Source={dbpath};";
    }

    builder.UseSqlite(connStr);
    return new AppDbContext(builder.Options);
  }
}

这里从环境变量读取数据库连接字符串,如果读不到就使用默认的数据库文件。

数据库迁移

这块主要是使用两组命令

  • migrations - 用于监控数据库的修改
  • database - 将修改同步到数据库里

cd 到 StarBlog.Data 目录下,执行

dotnet ef migrations add InitialCreate -o Migrations 

之后可以看到 Migrations 目录下生成了迁移的代码

如果需要指定数据库文件,可以设置环境变量。

Windows的使用:

set CONNECTION_STRING = "Data Source=app.db;"

Linux的也差不多,把 set 换成 export

export CONNECTION_STRING = "Data Source=app.db;"

运行以下命令同步到数据库

dotnet ef database update

执行之后就会在 StarBlog.Data 下生成 SQLite 数据库文件。

在AspNetCore项目里集成EFCore

先把数据库连接字符串写到配置文件 appsettings.json

{
  "ConnectionStrings": {
    "SQLite": "Data Source=app.db;Synchronous=Off;Cache Size=5000;",
    "SQLite-Log": "Data Source=app.log.db;"
  }
}

Program.cs 里注册服务

builder.Services.AddDbContext<AppDbContext>(options => {
  options.UseSqlite(builder.Configuration.GetConnectionString("SQLite-Log"));
});

搞定~

db-first

从已有数据库生成实体类,一般新项目不推荐这种开发方式,不过在旧项目上使用还是比较方便的,EFCore 的 cli tool 也提供很丰富的代码生成功能。

这里提供一下例子:

  • 使用 PostgreSql 数据库,要把其中 pe_shit_data 库的所有表生成实体类
  • 生成的 DbContext 类名为 ShitDbContext
  • DbContext 类的命名空间为 PE.Data
  • 实体类放在 ShitModels 目录下,命名空间为 PE.Data.ShitModels

命令如下

dotnet ef dbcontext scaffold `
    "Host=cuc.dou3.net;Database=pe_shit_data;Username=postgres;Password=passw0rd" `
    Npgsql.EntityFrameworkCore.PostgreSQL `
    -f `
    -c ShitDbContext `
    --context-dir . `
    --context-namespace PE.Data `
    -o ShitModels `
    --namespace PE.Data.ShitModels `

这个是 powershell 的命令,如果是 Linux 环境,把每一行命令末尾的反引号换成 \ 即可。

参考资料

与Asp-Net-Core开发笔记:快速在已有项目中引入EFCore相似的内容:

Asp-Net-Core开发笔记:快速在已有项目中引入EFCore

前言 很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是

Asp-Net-Core学习笔记:gRPC快速入门

## 前言 此前,我在做跨语言调用时,用的是 Facebook 的 Thrift,挺轻量的,还不错。 >Thrift是一种接口描述语言和二进制通讯协议,它被用来定义和创建跨语言的服务。它被当作一个远程过程调用(RPC)框架来使用,是由Facebook为“大规模跨语言服务开发”而开发的。它通过一个代码

Asp-Net-Core开发笔记:使用原生的接口限流功能

前言 之前介绍过使用 AspNetCoreRateLimit 组件来实现接口限流 从 .Net7 开始,AspNetCore 开始内置限流组件,当时我们的项目还在 .Net6 所以只能用第三方的 现在都升级到 .Net8 了,当然是得来试试这个原生组件 体验后:配置使用都比较简单,不过功能也没有 A

Asp-Net-Core开发笔记:给SwaggerUI加上登录保护功能

前言 在 SwaggerUI 中加入登录验证,是我很早前就做过的,不过之前的做法总感觉有点硬编码,最近 .Net8 增加了一个新特性:调用 MapSwagger().RequireAuthorization 来保护 Swagger UI ,但官方的这个功能又像半成品一样,只能使用 postman c

Asp-Net-Core开发笔记:使用ActionFilterAttribute实现非侵入式的参数校验

前言 在现代应用开发中,确保API的安全性和可靠性至关重要。 面向切面编程(AOP)通过将横切关注点(如验证、日志记录、异常处理)与核心业务逻辑分离,极大地提升了代码的模块化和可维护性。 在ASP.NET Core中,利用ActionFilterAttribute可以方便地实现AOP的理念,能够以简

Asp-Net-Core开发笔记:进一步实现非侵入性审计日志功能

前言 上次说了利用 AOP 思想实现了审计日志功能,不过有同学反馈还是无法实现完全无侵入,于是我又重构了一版新的。 回顾一下:Asp-Net-Core开发笔记:实现动态审计日志功能 现在已经可以实现对业务代码完全无侵入的审计日志了,在需要审计的接口上加上 [AuditLog] 特性,就可以记录这个接

Asp-Net-Core开发笔记:EFCore统一实体和属性命名风格

前言 C# 编码规范中,类和属性都是大写驼峰命名风格(PascalCase / UpperCamelCase),而在数据库中我们往往使用小写蛇形命名(snake_case),在默认情况下,EFCore会把原始的类名和属性名直接映射到数据库,这不符合数据库的命名规范。 为了符合命名规范,而且也为了看起

Asp-Net-Core开发笔记:使用RateLimit中间件实现接口限流

前言 最近一直在忙(2月份沉迷steam,3月开始工作各种忙),好久没更新博客了,不过也积累了一些,忙里偷闲记录一下。 这个需求是这样的,我之前做了个工单系统,现在要对登录、注册、发起工单这些功能做限流,不能让用户请求太频繁。 从 .Net7 开始,已经有内置的限流功能了,但目前我们的项目还在使用

Asp-Net-Core开发笔记:API版本管理

## 前言 对于Web API应用程序而言,随着时间的推移以及需求的增加或改变,API必然会遇到升级的需求。事实上,Web API应用程序应该从创建时就考虑到API版本的问题。业务的调整、功能的增加、接口的移除与改名、接口参数变动、实体属性的添加、删除和更改等都会改变API的功能,从而带来版本的变更

Asp-Net-Core开发笔记:FrameworkDependent搭配docker部署

## 前言 之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后