1. EF Core数据工程导论

在数据工程实践中，应用程序与数据库之间的交互往往占据大量开发与维护成本。若直接使用 ADO.NET 编写 SQL、手工映射 DataReader 到对象、自行管理连接与事务，代码会迅速被重复的样板逻辑淹没。ORM（Object-Relational Mapping，对象关系映射）正是为解决这一矛盾而出现的中间层技术：它在关系型数据库的表、行、列与面向对象语言中的类、对象、属性之间建立映射，让开发者以操作对象的方式完成数据持久化。EF Core（Entity Framework Core）是 .NET 平台上现代、跨平台、可扩展的 ORM 框架，也是数据工程中连接业务模型与关系数据库的重要基础设施。

ORM 的本质：不是替代 SQL，而是管理映射与生命周期

理解 ORM 的关键，是把它看作“映射 + 变更跟踪 + 命令生成 + 连接管理”的组合，而不是简单的 SQL 生成器。以一张 Orders 表为例，ORM 需要完成四件事：把 Order 类映射到表，把 Id、CustomerId、Amount 属性映射到列，跟踪对象从数据库读出后发生的修改，并在 SaveChanges() 时把这些修改翻译成 INSERT、UPDATE、DELETE 语句。EF Core 在此之上还提供 LINQ 查询翻译、关系导航、并发控制、迁移（Migrations）等能力。

需要明确的是，ORM 并不消灭 SQL。复杂报表、批量导入、窗口函数、数据库特有语法等场景，仍然更适合直接使用 SQL 或 Dapper 这类轻量映射器。EF Core 的定位是覆盖“以实体为中心的增删改查与关系维护”这一大类高频工作，同时通过 FromSqlRaw、ExecuteUpdate 等入口保留对原生 SQL 的通道。

EF Core 的核心组件与运行时结构

EF Core 的运行时可以拆成几个关键对象，它们共同决定了一次数据访问从代码到数据库再回到内存的完整路径。下图展示了这一结构关系：

EF Core 运行时核心组件与数据流 应用程序代码 LINQ / 实体操作 DbContext DbSet<T> · ChangeTracker SaveChanges() · 事务边界 Model（元数据） 实体 · 属性 · 关系 · 键 约定 / 数据注解 / Fluent API 数据库提供程序 SQL Server / PostgreSQL / SQLite SQL 命令 SELECT / INSERT / UPDATE / DELETE 关系数据库 表 · 索引 · 约束 · 事务 迁移 Migrations 模型 → 数据库架构演进 调用 读取 翻译 生成 执行 应用 更新模型

其中 DbContext 是会话级入口，代表一次工作单元；DbSet<T> 表示可查询的实体集合；ChangeTracker 记录实体状态（Added、Modified、Deleted、Unchanged）；Model 保存映射元数据；数据库提供程序负责把 LINQ 表达式树翻译为特定数据库方言的 SQL。迁移则把模型变化转化为可版本化的架构变更脚本。

适用场景与边界判断

EF Core 适合以下典型场景：以领域实体为中心的 CRUD 服务、需要关系导航与级联维护的业务系统、希望用 LINQ 获得编译期检查的查询逻辑、需要跨多种数据库保持代码一致性的产品。它不太适合：超大批量数据导入（应使用 SqlBulkCopy 或 COPY）、高度复杂的分析型 SQL、对每条语句执行计划有极致要求的低延迟场景。

一个实用的判断方法是看“数据访问是否以实体生命周期为主”。如果一次操作的核心是“取出订单、修改状态、保存”，EF Core 的变更跟踪会显著降低代码量；如果核心是“把 500 万行日志聚合到报表”，直接写 SQL 更合适。

版本演进与工程影响

EF Core 自 1.0 起持续演进，几个节点对数据工程影响明显：EF Core 2.x 引入 DbContextPool 与更完善的 LINQ 翻译；3.x 支持 Cosmos DB 与客户端求值限制；5.x 带来 Many-to-Many 原生支持与 SaveChanges 拦截器；6.x 强化了 ExecuteUpdate/ExecuteDelete 与编译模型；7.x 改进批量更新与 JSON 列；8.x 进一步优化复杂查询与 ExecuteUpdate 的灵活性。版本选择应结合目标数据库提供程序、.NET 运行时版本与团队升级成本，而不是盲目追新。

在数据工程中，EF Core 常与 Dapper、原生 SQL、存储过程共存。合理的分层是：写路径与关系维护交给 EF Core，读路径中的复杂报表交给 SQL，批量导入导出交给专用工具。

一个最小可运行的示例

下面示例使用 SQLite，定义一个 Product 实体，插入并查询数据。示例参数为教学假设，实际执行结果会因环境而异。

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public decimal Price { get; set; }
}

public class AppDbContext : DbContext
{
    public DbSet<Product> Products => Set<Product>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseSqlite("Data Source=shop.db");
}

using var db = new AppDbContext();
db.Database.EnsureCreated();

db.Products.Add(new Product { Name = "键盘", Price = 199.00m });
db.SaveChanges();

var list = db.Products.Where(p => p.Price > 100).OrderBy(p => p.Name).ToList();
foreach (var p in list)
    Console.WriteLine($"{p.Id} - {p.Name} - {p.Price}");

运行后，EnsureCreated() 会依据模型创建 Products 表，SaveChanges() 生成 INSERT，LINQ 查询被翻译为带 WHERE 与 ORDER BY 的 SELECT。若把 Price 改为 decimal(18,2) 并观察生成的 SQL，可以直观看到模型配置如何影响数据库列类型。

学习路径建议

掌握 EF Core 数据工程，建议按“模型映射 → 查询翻译 → 变更跟踪 → 迁移与架构演进 → 性能与并发 → 与原生 SQL 协作”的顺序推进。每一层都要能回答：输入是什么、EF Core 做了什么、数据库收到什么、结果如何验证。只有把这条链路走通，才能在真实项目中判断何时使用 ORM、何时绕过 ORM。

← 上一章 📖 返回目录 下一章 →