首先，我猜你说的EFW应该是笔误——大概率是指**Entity Framework (EF)**吧？毕竟这才是.NET生态里和ADO.NET常被拿来对比的主流ORM框架。结合你的项目（SPA、按日期查询数据、VS2017+SQL Server 2014+WebAPI+Angular），我给你梳理几个靠谱的方向：

一、优先考虑的替代方案：轻量ORM + 手动优化 #

1. Dapper #

这是Stack Overflow自家一直在用的轻量ORM，本质就是对ADO.NET的极简封装——性能几乎和纯ADO.NET持平，但能帮你省去手动映射DataReader到实体类的繁琐代码，编码量骤减。

针对你的日期查询场景，代码大概长这样：

using (var connection = new SqlConnection(yourConnectionString))
{
    var userData = connection.Query<UserData>(
        "SELECT * FROM UserData WHERE Date = @SelectedDate",
        new { SelectedDate = targetDate }
    ).ToList();
}

完全保留了写原生SQL的灵活性（方便你针对日期查询做索引优化），又不用处理连接管理、数据转换这些重复工作，完美契合你"高性能+低编码量"的需求。

2. EF Core #

如果你更习惯用LINQ写查询，不想手写太多SQL，EF Core是更好的选择。它是EF的轻量化、高性能迭代版本，适配你的VS2017和最新.NET框架（注意VS2017支持到.NET Core 3.1，要是用.NET Framework的话EF6也可以，但EF Core更推荐）。

针对性能顾虑，你可以做这些优化：

• 用AsNoTracking()关闭变更跟踪（你的场景以查询为主，不需要跟踪实体变更），能显著提升查询速度；
• 复杂查询直接用FromSqlRaw执行参数化原生SQL，避免LINQ转SQL的性能损耗；
• 提前编译常用查询（比如日期查询），减少运行时的表达式解析开销。

EF Core的编码量优势很明显：自动生成实体类和DbContext，常规CRUD几乎不用写SQL，后期维护也更方便。

二、如果一定要在ADO.NET和EF之间二选一 #

选ADO.NET的情况 #

只有当你的项目有极致性能要求（比如高并发下的毫秒级响应），或者需要处理大量复杂的存储过程、多表关联查询，且团队对ADO.NET的熟练度远高于ORM时，才考虑纯ADO.NET。它的优势是完全掌控SQL执行细节，但缺点也很突出：编码量大，需要手动处理连接、数据转换、异常捕获，后期维护成本高。

选EF的情况 #

如果你的项目以常规CRUD为主，日期查询这类操作不算特别复杂，EF的开发效率优势会非常明显。通过前面提到的优化手段，性能差距其实很小，完全能满足SPA的需求。而且EF的代码可读性更高，新人上手更快。

针对你的项目的最终建议 #

结合你的场景（查询密集型、SPA+WebAPI），我最推荐Dapper——它平衡了性能和开发效率，上手快，能完美适配你的日期查询需求；如果更偏爱LINQ的便捷性，就选EF Core，配合简单的优化就能达到接近ADO.NET的性能。只有当你有非常特殊的性能或复杂SQL需求时，才考虑纯ADO.NET。

内容的提问来源于stack exchange，提问作者Ravi Chanduri