[解决方案]数据库调用之：EF Core和 ADO.NET是队友配合关系，不是二选一
不要因为担心性能而全面抛弃 EF Core，那样会让你的 CRM 开发周期延长一倍且 BUG 频出。
假设企业级CRM系统，800人同时用(并发数约800*5)，访问数据库在EF Core和 ADO.NET之间如何选择？
这是一个非常专业且切中要害的问题。“800人同时在线”确实不等于“800个数据库请求/秒（QPS）”，实际负载通常是这个数字的 5-10 倍甚至更高。
例如：打开一个“客户详情页”，可能需要查询：客户基础信息、关联联系人、历史跟进记录、关联订单、权限验证等 5-6 次查询。如果页面设计不合理，甚至可能产生几十次查询。
从负载抗压能力和具体场景选型两个维度深入剖析。
一、 面对“查询倍增”的压力，EF Core 还能扛得住吗？
结论：能扛住，但前提是你会“用”。
如果不加优化，EF Core 确实容易在并发高时“卡死”数据库；但如果使用得当，它和 Dapper 的差距仅在毫秒级，完全可以支撑 800 并发 x 10 QPS 的量级。
针对你担心的“查询倍增”，EF Core 有针对性的解决方案，而 ADO.NET 则需要你手动去写这些逻辑：
-
连接池枯竭（Connection Pool Exhaustion）
- 风险： 800 人并发，如果每个请求都 new 一个 DbContext 且处理慢，数据库连接池瞬间就会被占满，导致后续请求报错。
- EF Core 对策： 使用
DbContext Pooling（上下文池化）。它复用 Context 实例，大幅降低创建开销。 - ADO.NET 对策： 你需要自己非常小心地管理 Connection 的 Open 和 Close，一旦漏写一个 Close，系统就崩了。
-
N+1 查询问题（性能杀手）
- 场景： 查询 100 个客户，循环显示他们的所属地区。
- 小白写法： 1 次查客户 + 100 次查地区 = 101 次查询。这是 EF Core 被诟病慢的主要原因。
- 优化写法： 使用
.Include(c => c.Region)，EF Core 会自动将其优化为 1 条 Join SQL 或 2 条 Split Query，将 101 次请求降为 1-2 次。
-
只读查询优化
- 场景： 列表页展示，不需要修改数据。
- EF Core 对策： 使用
.AsNoTracking()。这会关闭变更追踪（Change Tracking），内存占用减少 80%，速度提升显著。
我的建议修正：
考虑到“查询倍增”，在核心高频接口（如首页仪表盘、全局搜索），即使逻辑不复杂，也建议用 Dapper 手写 SQL 来减少 ORM 的开销；而在业务操作接口（如新建客户、审批流程），依然坚持用 EF Core。
二、 实战指南：什么场景用 EF Core vs Dapper/ADO.NET？
我们将 CRM 中的具体功能拆解，建立一个选型标准：
1. 必须使用 Entity Framework Core 的场景
关键词： 增删改、复杂业务逻辑、动态查询、强类型安全。
| 业务场景 | 理由 | 代码示例/解释 |
|---|---|---|
| 复杂表单提交 (新建客户、录入商机) |
事务一致性。往往涉及多张表（如：插入客户表 -> 插入联系人表 -> 插入日志表）。EF 的 SaveChanges() 自动开启事务，要么全成功要么全失败，极其安全。 |
_context.Customers.Add(c); _context.SaveChanges(); |
| 多条件组合搜索 (CRM核心筛选器) |
动态 SQL 生成。用户可能按“地区”搜，也可能按“行业+创建时间”搜。用 EF 的 IQueryable 拼接条件非常优雅；用 ADO.NET 拼接字符串简直是灾难。 |
query = query.Where(...)自动防御 SQL 注入。 |
| 简单的关联查询 (客户详情页) |
开发效率。主表关联 1-3 个子表，数据量不大（几万条以内）。 | .Include(x => x.Contacts).ThenInclude(...) |
| 字段校验/存在性检查 | 便捷性。检查手机号是否重复。 | _context.Customers.AnyAsync(c => c.Phone == "...") |
| 软删除/审计日志 | 全局过滤器。EF Core 支持 Global Query Filters，可以自动过滤掉 IsDeleted=true 的数据，防止开发者忘记写 Where。 |
配置一次，全局生效。 |
2. 必须使用 Dapper / ADO.NET 的场景
关键词： 极致性能、超复杂报表、批量操作、老旧存储过程。
| 业务场景 | 理由 | 代码示例/解释 |
|---|---|---|
| 首页仪表盘/统计报表 (销售漏斗、业绩排名) |
SQL 复杂度。涉及 GROUP BY、HAVING、窗口函数 ROW_NUMBER()、多层嵌套子查询。EF 生成的 SQL 往往不仅长，而且执行计划很差。 |
直接写 SQL，针对性优化索引。 |
| Excel 批量导入 (导入 5000 条线索) |
性能瓶颈。EF Core 即使优化过，插入 5000 条数据也比 ADO.NET 的 SqlBulkCopy 慢几十倍。 |
必须用 SqlBulkCopy (SQL Server) 或 PostgreSQL 的 COPY 命令。 |
| 超多表关联查询 (全景视图) |
笛卡尔积风险。如果一个查询关联了 6-7 张大表，EF Core 可能会把所有数据拉到内存处理，或者生成极其巨大的 SQL 导致数据库 CPU 飙升。 | 手写 SQL 精确控制只查需要的字段，而不是 SELECT *。 |
| 历史数据归档/清理 (每天凌晨跑的任务) |
批量更新/删除。比如：把 3 年前的日志状态改为“归档”。 | DELETE FROM Logs WHERE Date < ... 虽然 EF Core 7+ 支持 ExecuteDelete，但复杂逻辑下 SQL 更稳。 |
| 调用存储过程 | 兼容性。如果你们有一些遗留的存储过程处理复杂的业务计算。 | Dapper 调用存储过程极其方便：connection.Query("sp_Name", ..., commandType: StoredProcedure) |
三、 混合架构的“黄金法则”
在你的 CRM 系统代码中，我建议采用 CQRS（命令查询职责分离） 的简化版思维：
- Command（写操作）：100% 使用 EF Core。
- 因为写操作频率相对低（相比于读），且逻辑严密性要求高。EF Core 的变更追踪和事务机制能救你的命。
- Query（读操作）：80/20 原则。
- 80% 的常规读取（详情、简单列表）： 用 EF Core（记得加
AsNoTracking）。 - 20% 的重度读取（报表、大数据量列表、大屏接口）： 用 Dapper。
- 80% 的常规读取（详情、简单列表）： 用 EF Core（记得加
四、 针对你 800 人并发的最终建议
既然你提到了数据库请求可能会翻倍，除了选型，你必须在架构层面做这三件事，否则选 ADO.NET 也救不了你：
-
读写分离（Read/Write Splitting）：
- CRM 是典型的读多写少。建议配置数据库的主从复制。
- 所有的报表、统计、列表查询（Dapper 部分）去连从库（Read Replica）。
- 所有的增删改（EF Core 部分）连主库（Master）。
- 这样 800 人的查询压力就被分摊了。
-
缓存策略（Redis）：
- 不要让“权限验证”、“下拉菜单选项（数据字典）”、“组织架构”这种万年不变的数据每次都去查数据库。
- 这些高频小查询占了数据库请求的一大半，把它们挡在 Redis 层，数据库 QPS 直接腰斩。
-
精细化索引：
- 不要只盯着 ORM。打开 SQL Server Profiler 或其他监控工具，抓取那些执行超过 500ms 的语句。通常你会发现，一个漏加的索引比换掉 EF Core 致命得多。
总结：
不要因为担心性能而全面抛弃 EF Core，那样会让你的 CRM 开发周期延长一倍且 BUG 频出。“EF Core 处理业务逻辑 + Dapper 处理复杂报表 + Redis 挡住高频字典查询”，这是目前 .NET 生态中最稳健的企业级打法。
火山引擎开发者社区是火山引擎打造的AI技术生态平台，聚焦Agent与大模型开发，提供豆包系列模型（图像/视频/视觉）、智能分析与会话工具，并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长，新用户可领50万Tokens权益，助力构建智能应用。
更多推荐
22
0- 0
已为社区贡献1条内容
所有评论(0)