做数据访问
本页面面向需要落地数据访问的人。当前默认路径已经收敛为 Dapper / SQL，EF Core 只作为存量项目兼容方案保留。
我现在要解决什么
- 新项目应该怎样按 Dapper 路线组织 Repository。
- 存量 EF Core 项目什么时候该迁、怎么迁到 Dapper。
- 审计字段、并发控制和事务为什么仍依赖
WorkContext。 - 数据库命名和仓储命名如何统一。
先看哪几页
最短落地路径
- 新项目：直接按 数据访问 的 Dapper 主路径建业务 Repository。
- 存量 EF Core：先读 EF Core 迁移到 Dapper，不要继续扩展 EF Core 面。
先选访问模型，再选仓储基类
- 新项目默认先选
SqlBaseRepository。 - 如果需求是复杂列表、分页、多表 SQL、事务或并发控制，继续沿 Dapper 路线细化业务仓储。
- 如果当前模块已经落在 EF Core 上，先判断是否能直接迁到 Dapper，而不是继续新增
DbContext、CrudRepository或 EF Core migration。
落地顺序
- 先确定新模块不再新增 EF Core 接入。
- 再按业务边界定义 Dapper Repository。
- 最后把审计字段、事务和并发控制显式落在 Repository 或其相邻应用层里。
保存链路排查点
- 写入 SQL 是否明确包含并发字段、租户条件和影响行数校验。
- 审计字段是否显式从当前
WorkContext补齐。 - 涉及多步写入时是否明确使用事务，而不是依赖隐式提交。
- 后台任务里的保存逻辑是否先创建了新的 WorkContext Scope。
如果当前项目已经用了 EF Core
- 不要继续把新业务挂到
DbContext或CrudRepository上。 - 优先把查询、分页和报表迁到 Dapper。
- 写入迁移时同步收敛并发控制、审计字段和事务边界。
- 迁移规范统一看 EF Core 迁移到 Dapper。
真实项目怎么做
- niusys-webapi：适合看旧的
DbContext兼容路径，不适合作为新项目默认模板。 - gmandarin-backend：大量显式业务仓储。
- woscm：重点看项目级 Dapper 基类与
ts并发控制。