Arm*_*our 1 c# entity-framework entity-framework-core
请考虑以下假设：
EF以及如何以最佳方式正确使用它。EF由于其兼容性OOP和易用性，我更喜欢在我的应用程序中使用。我知道EF（即使使用最佳实践）与Dapperor相比有一些性能下降ADO.NET。
但我的问题是，根据我的假设，这个性能问题是相当大的还是我可以EF在我的高流量 Web 应用程序中安全使用？
小智 8
我有一个高流量的 Web 应用程序，数据库表中有数百万条记录。
除非您忘记在其上放置索引，否则没有人（主要不是数据库）关心数百万条记录。更有趣的是查询的复杂程度。大多数查询 - 特别是那些至少可以使用索引来减少解析的数量的查询 - 对数十亿条记录的负载微不足道，但是超过 15 个表的连接强制将 100GB 的数据放入 tempdb 是一个问题。
我对 EF 以及如何以最优化的方式正确使用它有足够的了解。
我对此表示怀疑，尤其是对于似乎每个周末都在变化的 EF Core。但是好吧，您确实避免了最愚蠢的事情，例如整个应用程序的一个 dbcontext。
我知道 EF 即使使用最佳实践，与 Dapper 或 ADO 相比也有一些性能下降。
这完全不是真的。重点是 - EF 做了很多 Dapper 和 ADO 都没有直接做的事情，而且这是有代价的。这就像“法拉利比卡车快，但也有缺点”。
卡车很慢——除非你运送很多东西。即查询会带来很多开销 - 但如果您不关心更新您查询的数据（在 Web 应用程序中很常见），那么请关闭此查询的更改跟踪。获取对象有开销 - 好吧，发生了。
但是您可以过滤实现哪些属性。这样做，数据量就会下降。EF 并不完全是超快的——但它也不完全是糟糕的。Dapper 和 ADO(.NET) 击败了它，但它们做得更少。
事实上，EF 是建立在 ADO.NET 之上的，因为除非您打算自己编写整个网络堆栈，否则 ADO.NET 是与大多数数据库对话的唯一途径。
整个问题是：你认为什么是高流量？我已经看到 EF 成功部署在具有数万个并行用户的应用程序中。然后我将一些关键函数的速度提高了 100 倍，因为专业程序员对 EF 了如指掌——但没有人教他们如何在表上放置正确的索引。
EF 在大型应用程序上完全有能力，但根据使用情况，您可能必须扩展到某些服务器，除非您编写非常高效的用户级代码并避免低效的事情，例如枚举所有值然后在内存中过滤（是的，我已经看到了这一点- 特别是“我们在 EF 周围做存储库”的人，然后认为返回 anIEnumerable是一个好主意）。