- A+
1. 快速入门
创建新的控制台项目
dotnet new console -o EFGetStarted cd EFGetStarted
安装 Entity Framework Core
要安装 EF Core，请为要作为目标对象的 EF Core 数据库提供程序安装程序包。 本教程使用 SQLite 的原因是，它可在 .NET Core 支持的所有平台上运行 。
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
创建模型
定义构成模型的上下文类和实体类。
using Microsoft.EntityFrameworkCore; using System; using System.Collections.Generic; public class BloggingContext : DbContext { public DbSet<Blog> Blogs { get; set; } public DbSet<Post> Posts { get; set; } public string DbPath { get; } public BloggingContext() { var folder = Environment.SpecialFolder.LocalApplicationData; var path = Environment.GetFolderPath(folder); DbPath = System.IO.Path.Join(path, "blogging.db"); } // 配置SQLLite连接字符串（其实就是提供一个本地文件夹用于放数据而已） protected override void OnConfiguring(DbContextOptionsBuilder options) => options.UseSqlite($"Data Source={DbPath}"); } public class Blog { public int BlogId { get; set; } public string? Url { get; set; } public List<Post> Posts { get; } = new(); } public class Post { public int PostId { get; set; } public string? Title { get; set; } public string? Content { get; set; } public int BlogId { get; set; } public Blog? Blog { get; set; } }
创建数据库
dotnet tool install --global dotnet-ef dotnet add package Microsoft.EntityFrameworkCore.Design --version 6.0.4 dotnet ef migrations add InitialCreate dotnet ef database update
这会安装 dotnet ef 和设计包，这是对项目运行命令所必需的。 migrations 命令为迁移搭建基架，以便为模型创建一组初始表。 database update 命令创建数据库并向其应用新的迁移。
CURD
打开 Program.cs 并将内容替换为以下代码
using System; using System.Linq; using var db = new BloggingContext(); Console.WriteLine($"Database path: {db.DbPath}."); // 新增 Console.WriteLine("新增了一条blog"); db.Add(new Blog { Url = "http://blogs.msdn.com/adonet" }); db.SaveChanges(); // 读取 Console.WriteLine("查询一条blog"); var blog = db.Blogs .OrderBy(b => b.BlogId) .First(); // 更新 Console.WriteLine("更新 blog 并且 添加一条 post数据"); blog.Url = "https://devblogs.microsoft.com/dotnet"; blog.Posts.Add( new Post { Title = "Hello World", Content = "I wrote an app using EF Core!" }); db.SaveChanges(); // 删除 Console.WriteLine("删除 blog"); db.Remove(blog); db.SaveChanges(); // 释放资源 db.Dispose();
运行：
dotnet run
2. 数据库上下文
1. DbContext 生命周期
DbContext 的生命周期从创建实例时开始，并在释放实例时结束。 DbContext 实例旨在用于单个工作单元。 这意味着 DbContext 实例的生命周期通常很短。
提示
引用上述链接中 Martin Fowler 的话，“工作单元将持续跟踪在可能影响数据库的业务事务中执行的所有操作。 当你完成操作后，它将找出更改数据库作为工作结果时需要执行的所有操作。”
使用 Entity Framework Core (EF Core) 时的典型工作单元包括：
-
创建
DbContext实例 -
根据上下文跟踪实体实例。 实体将在以下情况下被跟踪
-
根据需要对所跟踪的实体进行更改以实现业务规则
-
调用 SaveChanges 或 SaveChangesAsync。 EF Core 检测所做的更改，并将这些更改写入数据库。
-
释放
DbContext实例
重要
使用后释放 DbContext 非常重要。 这可确保释放所有非托管资源，并注销任何事件或其他挂钩，以防止在实例保持引用时出现内存泄漏。
DbContext 不是线程安全的。 不要在线程之间共享上下文。 请确保在继续使用上下文实例之前，等待所有异步调用。
EF Core 代码引发的 InvalidOperationException 可以使上下文进入不可恢复的状态。 此类异常指示程序错误，并且不旨在从其中恢复。
2. ASP.NET Core 注入中的 DbContext
在许多 Web 应用程序中，每个 HTTP 请求都对应于单个工作单元。 这使得上下文生存期与请求的生存期相关，成为 Web 应用程序的一个良好默认值。
使用依赖关系注入配置 ASP.NET Core 应用程序。 可以使用 Startup.cs 的 ConfigureServices 方法中的 AddDbContext 将 EF Core 添加到此配置。 例如：
public void ConfigureServices(IServiceCollection services) { services.AddControllers(); services.AddDbContext<ApplicationDbContext>( options => options.UseSqlServer("name=ConnectionStrings:DefaultConnection")); }
此示例将名为 ApplicationDbContext 的 DbContext 子类注册为 ASP.NET Core 应用程序服务提供程序（也称为依赖关系注入容器）中的作用域服务。 上下文配置为使用 SQL Server 数据库提供程序，并将从 ASP.NET Core 配置读取连接字符串。 在 ConfigureServices 中的何处调用 AddDbContext 通常不重要。
ApplicationDbContext 类必须公开具有 DbContextOptions<ApplicationDbContext> 参数的公共构造函数。 这是将 AddDbContext 的上下文配置传递到 DbContext 的方式。 例如：
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } }
然后，ApplicationDbContext 可以通过构造函数注入在 ASP.NET Core 控制器或其他服务中使用。 例如：
public class MyController { private readonly ApplicationDbContext _context; public MyController(ApplicationDbContext context) { _context = context; } }
最终结果是为每个请求创建一个 ApplicationDbContext 实例，并传递给控制器，并且在请求结束后释放DbContext。
有关配置选项的详细信息，请进一步阅读本文。 此外，有关 ASP.NET Core 中的配置和依赖关系注入的详细信息，请参阅 ASP.NET Core 中的应用启动和 ASP.NET Core 中的依赖关系注入。
3. “new”一个 DbContext
可以按照常规的 .NET 方式构造 DbContext 实例，例如，使用 C# 中的 new。 可以通过重写 OnConfiguring 方法或通过将选项传递给构造函数来执行配置。 例如：
public class ApplicationDbContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Test"); } }
通过此模式，还可以轻松地通过 DbContext 构造函数传递配置（如连接字符串）。 例如：
public class ApplicationDbContext : DbContext { private readonly string _connectionString; public ApplicationDbContext(string connectionString) { _connectionString = connectionString; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(_connectionString); } }
或者，可以使用 DbContextOptionsBuilder 创建 DbContextOptions 对象，然后将该对象传递到 DbContext 构造函数。 这使得为依赖关系注入配置的 DbContext 也能显式构造。 例如，使用上述为 ASP.NET Core 的 Web 应用定义的 ApplicationDbContext 时：
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } } 可以创建 DbContextOptions，并可以显式调用构造函数： var contextOptions = new DbContextOptionsBuilder<ApplicationDbContext>() .UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Test") .Options; using var context = new ApplicationDbContext(contextOptions);
4. DbContext 工厂
某些应用程序类型（例如 ASP.NET Core Blazor）使用依赖关系注入，但不创建与所需的 DbContext 生存期一致的服务作用域。 即使存在这样的对齐方式，应用程序也可能需要在此作用域内执行多个工作单元。 例如，单个 HTTP 请求中的多个工作单元。
在这些情况下，可以使用 AddDbContextFactory 来注册工厂以创建 DbContext 实例。 例如：
public void ConfigureServices(IServiceCollection services) { services.AddDbContextFactory<ApplicationDbContext>( options => options.UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Test")); }
ApplicationDbContext 类必须公开具有 DbContextOptions<ApplicationDbContext> 参数的公共构造函数。 此模式与上面传统 ASP.NET Core 部分中使用的模式相同。
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } }
然后，可以通过构造函数注入在其他服务中使用 DbContextFactory 工厂。 例如：
private readonly IDbContextFactory<ApplicationDbContext> _contextFactory; public MyController(IDbContextFactory<ApplicationDbContext> contextFactory) { _contextFactory = contextFactory; }
然后，可以使用注入的工厂在服务代码中构造 DbContext 实例。 例如：
public void DoSomething() { using (var context = _contextFactory.CreateDbContext()) { // ... } }
请注意，以这种方式创建的 DbContext 实例并非由应用程序的服务提供程序进行管理，因此必须由应用程序释放。
5. 配置数据库提供程序
每个 DbContext 实例都必须配置为使用一个且仅一个数据库提供程序。 （DbContext 子类型的不同实例可用于不同的数据库提供程序，但一个实例只能使用一个。）一个数据库提供程序要使用一个特定的 Use* 调用进行配置。 例如，若要使用 SQL Server 数据库提供程序：
public class ApplicationDbContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Test"); } }
这些 Use* 方法是由数据库提供程序实现的扩展方法。 这意味着必须先安装数据库提供程序 NuGet 包，然后才能使用扩展方法。
提示
EF Core 数据库提供程序广泛使用扩展方法。 如果编译器指示找不到方法，请确保已安装提供程序的 NuGet 包，并且你在代码中已有 using Microsoft.EntityFrameworkCore;。
下表包含常见数据库提供程序的示例。
| 数据库系统 | 配置示例 | NuGet 程序包 |
|---|---|---|
| SQL Server 或 Azure SQL | .UseSqlServer(connectionString) |
Microsoft.EntityFrameworkCore.SqlServer |
| Azure Cosmos DB | .UseCosmos(connectionString, databaseName) |
Microsoft.EntityFrameworkCore.Cosmos |
| SQLite | .UseSqlite(connectionString) |
Microsoft.EntityFrameworkCore.Sqlite |
| EF Core 内存中数据库 | .UseInMemoryDatabase(databaseName) |
Microsoft.EntityFrameworkCore.InMemory |
| PostgreSQL* | .UseNpgsql(connectionString) |
Npgsql.EntityFrameworkCore.PostgreSQL |
| MySQL/MariaDB* | .UseMySql(connectionString) |
Pomelo.EntityFrameworkCore.MySql |
| Oracle* | .UseOracle(connectionString) |
Oracle.EntityFrameworkCore |
警告
EF Core 内存中数据库不是为生产用途设计的。 此外，它可能不是测试的最佳选择。 有关详细信息，请参阅使用 EF Core 的测试代码。
特定于数据库提供程序的可选配置是在其他特定于提供程序的生成器中执行的。 例如，在连接到 Azure SQL 时，使用 EnableRetryOnFailure 为连接复原配置重试：
public class ApplicationDbContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder .UseSqlServer( @"Server=(localdb)mssqllocaldb;Database=Test", providerOptions => { providerOptions.EnableRetryOnFailure(); }); } }
提示
同一数据库提供程序用于 SQL Server 和 Azure SQL。 但是，建议在连接到 SQL Azure 时使用连接复原。
6. 其他 DbContext 配置
其他 DbContext 配置可以链接到 Use* 调用之前或之后（这不会有任何差别）。 例如，若要启用敏感数据日志记录：
public class ApplicationDbContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder .EnableSensitiveDataLogging() .UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Test"); } }
下表包含 DbContextOptionsBuilder 调用的常见方法的示例。
| DbContextOptionsBuilder 方法 | 作用 | 了解更多 |
|---|---|---|
| UseQueryTrackingBehavior | 设置查询的默认跟踪行为 | 查询跟踪行为 |
| LogTo | 获取 EF Core 日志的一种简单方法（EF Core 5.0 及更高版本） | 日志记录、事件和诊断 |
| UseLoggerFactory | 注册 Microsoft.Extensions.Logging 工厂 |
日志记录、事件和诊断 |
| EnableSensitiveDataLogging | 在异常和日志记录中包括应用程序数据 | 日志记录、事件和诊断 |
| EnableDetailedErrors | 更详细的查询错误（以性能为代价） | 日志记录、事件和诊断 |
| ConfigureWarnings | 忽略或引发警告和其他事件 | 日志记录、事件和诊断 |
| AddInterceptors | 注册 EF Core 侦听器 | 日志记录、事件和诊断 |
| UseLazyLoadingProxies | 使用动态代理进行延迟加载 | 延迟加载 |
| UseChangeTrackingProxies | 使用动态代理进行更改跟踪 | 即将推出... |
7. DbContextOptions 与 DbContextOptions<TContext>
大多数接受 DbContextOptions 的 DbContext 子类应使用 泛型DbContextOptionsTContext>变体。 例如：
public sealed class SealedApplicationDbContext : DbContext { public SealedApplicationDbContext(DbContextOptions<SealedApplicationDbContext> contextOptions) : base(contextOptions) { } }
这可确保从依赖关系注入中解析特定 DbContext 子类型的正确选项，即使注册了多个 DbContext 子类型也是如此。
提示
你的 DbContext 不需要密封，但对于没有被设计为继承的类，密封是最佳做法。
但是，如果 DbContext 子类型本身旨在继承，则它应公开采用非泛型 DbContextOptions 的受保护构造函数。 例如：
public abstract class ApplicationDbContextBase : DbContext { protected ApplicationDbContextBase(DbContextOptions contextOptions) : base(contextOptions) { } }
这允许多个具体子类使用其不同的泛型 DbContextOptions<TContext> 实例来调用此基构造函数。 例如：
public sealed class ApplicationDbContext1 : ApplicationDbContextBase { public ApplicationDbContext1(DbContextOptions<ApplicationDbContext1> contextOptions) : base(contextOptions) { } } public sealed class ApplicationDbContext2 : ApplicationDbContextBase { public ApplicationDbContext2(DbContextOptions<ApplicationDbContext2> contextOptions) : base(contextOptions) { } }
请注意，这与直接从 DbContext 继承的模式完全相同。 也就是说，出于此原因，DbContext 构造函数本身将接受非泛型 DbContextOptions。
旨在同时进行实例化和继承的 DbContext 子类应公开构造函数的两种形式。 例如：
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> contextOptions) : base(contextOptions) { } protected ApplicationDbContext(DbContextOptions contextOptions) : base(contextOptions) { } }
8. 避免 DbContext 线程处理问题
Entity Framework Core 不支持在同一 DbContext 实例上运行多个并行操作。 这包括异步查询的并行执行以及从多个线程进行的任何显式并发使用。 在这个上下文，使用 await 来确保所有的异步操作完成于另一个方法调用之前。
当 EF Core 检测到尝试同时使用 DbContext 实例的情况时，你将看到 InvalidOperationException，其中包含类似于以下内容的消息：
在同一个上下文，一个异步操作还没完成，另一个操作就开始了。。 这通常是由使用同一个 DbContext 实例的不同线程引起的，但不保证实例成员是线程安全的。
检测不到并发访问时，可能会导致未定义的行为、应用程序崩溃和数据损坏。
3. 上下文池
DbContext 通常是一个轻型对象：创建和释放它不涉及数据库操作，而大多数应用程序都可以这样做，而不会对性能产生任何明显的影响。 但是，每个上下文实例确实设置了执行其职责所需的各种内部服务和对象，在高性能方案中，持续执行此操作的开销可能很大。 对于这些情况，EF Core 可以 共用 上下文实例：释放上下文时，EF Core 会重置其状态并将其存储在内部池中;下一次请求新实例时，将返回该共用实例，而不是设置新的实例。 上下文池允许你在程序启动时仅支付一次上下文设置成本，而不是连续付费。
请注意，上下文池与数据库连接池正交，后者在数据库驱动程序的较低级别进行管理。
依赖注入形式
使用 EF Core 的 ASP.NET Core 应用中的典型模式涉及通过 AddDbContext将自定义DbContext类型注册到依赖项注入容器中。 然后，将通过控制器或 Razor Pages 中的构造函数参数获取该类型的实例。
若要启用上下文池，AddDbContext只需将 替换为 AddDbContextPool：
builder.Services.AddDbContextPool<WeatherForecastContext>( o => o.UseSqlServer(builder.Configuration.GetConnectionString("WeatherForecastContext")));
参数poolSizeAddDbContextPool设置池保留的最大实例数， (EF Core 6.0 中默认为 1024，在) 早期版本中默认为 128。 一旦超过 poolSize，就不会缓存新的上下文实例，EF 会回退到按需创建实例的非池行为。
非依赖注入形式
EF Core 6.0 引入无需依赖关系注入的池。
若要在不使用依赖项注入的情况下使用上下文池，请 PooledDbContextFactory 初始化 并从中请求上下文实例：
var options = new DbContextOptionsBuilder<PooledBloggingContext>() .UseSqlServer(@"Server=(localdb)mssqllocaldb;Database=Blogging;Trusted_Connection=True") .Options; var factory = new PooledDbContextFactory<PooledBloggingContext>(options); using (var context = factory.CreateDbContext()) { var allPosts = context.Posts.ToList(); }
PooledDbContextFactory 构造函数的 poolSize 参数设置池保留的最大实例数（在 EF Core 6.0 中默认为 1024，在以前的版本中为 128）。 一旦超过 poolSize，就不会缓存新的上下文实例，EF 会回退到按需创建实例的非池行为。
连接池优化
连接池溢出的问题：
System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. at System.Data.Common.ADP.ExceptionWithStackTrace(Exception e)
每个 DbContext 实例都会占用一个数据库连接（SqlConnection），不启用 DbContextPool 的时候，请求一结束，对应 DbContext 实例就被 Dispose ，数据库连接就会被放回连接池。而使用 DbContextPool 的时候，请求结束后 DbContext 不会被 Dispose 而是被放回 DbContextPool ，DbContext 被放回属于自己的池中，就意味它对应的数据库连接不会被放回它所属的连接池。DbContextPool 中的每一个 DbContext 都对应一个数据库连接，DbContextPool 中每多一个 DbContext ，数据库连接池中就会少一个数据库连接。当这两个池的大小不一样且 DbContextPool 大于数据库连接池，问题就来了，DbContextPool 根据自家池（假设是128）子的大小畅快地向池中填 DbContext ，浑然不顾数据库连接池的大小(假设是100)，当填到第 101 个 DbContext 时就会出现上面的错误。
解决办法：
可以有两种方法：
-
将DbContextPool大小设置为比数据库最大连接数小即可
-
以Mysql为例，查询当前MySQL最大连接数据
show variables like '%max_connections%';
-
设置DbContextPool池大小
builder.Services.AddDbContextPool<MySqlBlogContext>(p => { p.UseMySql(builder.Configuration.GetConnectionString("MySQL"), new MySqlServerVersion("5.7")); },poolSize:127);
-
-
如果数据库服务器性能较好，可以将数据库最大连接数设置为比DbContextPool大
-
修改mysql.ini 文件，位置是：C:ProgramDataMySQLMySQL Server 5.7
-
如果是Docker 中的mysql, 配置文件需要编辑my.cnf文件（docker 安装时不存在这个文件）
vim /etc/mysql/my.cnf ## my.cnf 文件中编写如下配置 [mysqld] max_connections = 1025
-
找到
max_connections这个配置，设置为1025（因为EfCore6.0 默认的大小为1024） -
重启Mysql服务
-
![[C#] Bgr24彩色位图转为灰度的Bgr24位图的跨平台SIMD硬件加速向量算法](https://www.ztsky.cn/wp-content/themes/ztsky/img/random/3.jpg)
