.net - Entity Framework 太慢。我有什么选择？

Question

已结束。此问题正在寻求书籍、工具、软件库等的推荐。它不满足 Stack Overflow guidelines 。目前不接受答案。

---

我们不允许提出寻求书籍、工具、软件库等推荐的问题。您可以编辑问题，以便用事实和引文来回答。

已关闭 6 年前。

Improve this question

我遵循“不要过早优化”的原则，并使用 Entity Framework 编写了我的 WCF 服务。

但是，我分析了性能， Entity Framework 太慢了。 (我的应用程序在大约 1.2 秒内处理 2 条消息，而我正在重写的(旧版)应用程序同时处理 5-6 条消息。(旧版应用程序调用 sprocs 进行数据库访问。)

我的分析表明 Entity Framework 占用了每条消息的大部分时间。

那么，我有什么选择呢？

• 有更好的 ORM 吗？
  (只支持对象的正常读写并且速度很快......)

• 有没有办法让 Entity Framework 更快？
  (注意:当我说更快时，我的意思是从长远来看，而不是第一次调用。(第一次调用很慢(一条消息需要 15 秒)，但这不是问题。我只需要它对于其余消息来说速度很快。)

• 一些神秘的第三个选项将帮助我提高服务速度。

注意:我的大多数数据库交互都是创建和更新。我很少进行选择和删除。

Answer 1

事实是，诸如 Entity Framework 之类的产品总是缓慢且低效，因为它们正在执行更多的代码。

我还发现人们建议应该优化 LINQ 查询、查看生成的 SQL、使用调试器、预编译、采取许多额外步骤等，即浪费大量时间，这很愚蠢。没有人说——简化!每个人都想通过采取更多步骤来使事情变得更加复杂(浪费时间)。

常识性的做法是根本不使用 EF 或 LINQ。使用简单的 SQL。没有什么问题。仅仅因为程序员中有从众心理，他们有使用每一个新产品的冲动，并不意味着它是好的或会起作用。大多数程序员认为，如果他们合并大公司发布的每一段新代码，就会使他们成为更聪明的程序员；根本不是真的。智能编程主要是关于如何在最短的时间内以更少的麻烦、不确定性做更多的事情。记住——时间!这是最重要的元素，因此请尝试找到方法，不要将其浪费在解决仅仅为了符合某些奇怪的所谓“模式”而编写的糟糕/臃肿代码中的问题

放松，享受生活，从编码中休息一下，停止使用额外的功能、代码、产品、“模式”。生命短暂，代码的生命更短，这当然不是火箭科学。删除 LINQ、EF 等层，您的代码将高效运行、可扩展，而且，它仍然易于维护。太多的抽象是一个不好的“模式”。

这就是您问题的解决方案。