ASP.NET Core 5访问只读第二SQL数据库的EF Core与ADO.NET方案咨询

这种仅需读取少量外部业务库表的场景，优先选择定制化EF Core DB First方案，特殊复杂查询可辅以原生ADO.NET，比直接使用原生ADO.NET或全量生成DB First上下文更适配你的现有技术栈。

不推荐全量DB First的原因 #

你担心的全库生成冗余问题本身可以通过EF Core脚手架命令的参数完全避免，无需生成全库的DbContext和DbSet：

• 执行脚手架命令时通过-Tables参数指定你需要的8-10张表即可，仅生成目标表对应的实体和上下文配置，示例命令：
  Scaffold-DbContext "外部数据库连接字符串" Microsoft.EntityFrameworkCore.SqlServer -Tables 表名1,表名2,表名3... -OutputDir 实体输出目录 -Context 外部库只读DbContext名称 -NoOnConfiguring
• 生成的上下文可额外配置只读适配，关闭EF Core默认追踪进一步降低性能开销：在上下文的OnConfiguring方法中添加optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);，所有查询默认不做实体追踪，完全匹配只读场景需求。

优先选择EF Core而非原生ADO.NET的原因 #

• 你现有技术栈已经基于EF Core实现，无需额外投入ADO.NET封装、数据映射的开发成本，全项目数据库操作风格统一，后续维护门槛更低。
• 自带LINQ查询能力，比手写SQL更易维护，大部分语法错误可在编译期发现，避免手写SQL的拼写、参数绑定问题。
• 自动完成查询结果到实体的映射，无需手动编写DataReader到POCO的转换逻辑，减少重复代码量。

原生ADO.NET的适用场景 #

如果遇到多表关联的复杂聚合查询、EF Core生成的SQL性能不符合预期的情况，不需要完全切换到ADO.NET技术栈：可直接在EF Core上下文中通过FromSqlRaw方法执行手写原生SQL，或者调用EF Core暴露的底层数据库连接接口执行ADO.NET逻辑，复用现有上下文配置即可。

项目集成注意事项 #

• 外部库的实体和上下文单独封装在独立类库中，和自有库的实体项目解耦，在Web API项目中单独注入该只读DbContext，指定对应的连接字符串即可。
• 不要手动修改自动生成的外部库实体和上下文配置，后续外部库表结构变动时，重新执行一次带-Tables参数的脚手架命令覆盖生成即可，维护成本极低。

内容的提问来源于stack exchange，提问作者Mayuri Barve