在Dapper和实体框架中处理对象的方式（使用原始SQL查询）之间有什么区别？

据我所知，Dapper被认为更为SQL友好，但实体框架（EF）允许原始SQL。我通常使用SQL，但我喜欢EF中的一些东西。我的许多查询都相当复杂，涉及多个数据库和数据库引擎，而且大多数都不仅仅是简单的CRUD

说到使用SQL，处理对象的方式有什么不同？当我发出查询时，如果返回某个内容并将其分配给

列表

类型，它们是否相同

---

我使用的是ASP.NET Core 1.x。

两者之间可能存在一些性能差异，但对于原始SQL查询，两者都将填充您的IList（无论什么）。如果您计划为大多数/所有数据库交互编写自己的复杂SQL，那么dapper可能是更好的选择，因为它不会带来EF的所有开销。另一方面，如果您想利用代码优先迁移、更改跟踪等功能，或者您想用代码（而不是原始SQL）完成大部分数据库工作，那么EF是有意义的

---

这就是说，你最好的选择可能是花一点时间和这两个人在一起。您可能会发现，一旦开始使用它们，很快就可以做出决定。

如果您使用EF发出SQL请求，那么实际上并没有使用EF。这些调用是与ADO等价的逐行调用，并且要定义和维护的结果对象的加载非常简单。很多人使用EF，但在他们想使用原始SQL的时候使用Dapper。Dapper缓存结果集到POCO的映射，因此后续查询运行得更快。我认为EF不会这样做。此外，参数处理也更加简洁

---

但您仍然需要使用字符串文本中的SQL，每个错误都是运行时错误，您必须编写和维护结果POCOs。我主张，如果你使用，你会更快乐，寿命更长（免责声明：我写的）。在.SQL文件中输入SQL，并在键入时验证语法。在设计时根据查询结果生成POCO。您的查询不断经过集成测试，我很快就会记录下来

我有点好奇你怎么能“喜欢EF中的一些东西”？EF是一幅包罗万象的图画。您成功地隔离并喜欢哪一点？就性能而言，EF Core 2和Dapper之间的差异不像过去那样大：