传统的 sql 方法 VS ORM [关闭]答案

【问题标题】：Traditional sql approach VS ORM [closed]传统的 sql 方法 VS ORM [关闭]
【发布时间】：2015-08-11 11:09:26
【问题描述】：

我真的很沮丧寻找更好的答案 - 传统的 System.Data.SqlClient 方法或使用任何 ORM，如 EF 或 Dapper 我通过许多链接看到了很多比较，其中一些是：

我可以理解的一点是，手写的传统 sql 代码在性能上比任何其他方法都要好。但我仍然在想，如果我们已经有了最好的方法，那么为什么要使用 ORM？

仅仅是因为我们想减少DataLayer代码吗？或者我们不想管理我们的数据库并想在我们的 c# 代码中编写所有内容（代码/数据优先）

为什么要引入 EF，如果问题只是代码管理的话，我们为什么以及如何在查询执行的性能和速度上妥协，甚至 ORM 也有限制。

请回答我的问题，如果需要任何编辑，请告诉我。

我唯一关心的是我的网站的速度和性能。

提前致谢。

【问题讨论】：

您的问题是征求意见和建议，而 Stack Overflow 不允许这两者。
请建议，我应该将我的问题移至 StachExchange 吗？
程序员 StackExchange 会更好。
“我唯一关心的是我的网站的速度和性能。”如果这是真的，那你为什么不把它写在汇编程序中呢？可能不会，因为与高级语言相比，这太难了。这是一个极端的例子，但 ORM 也有类似的权衡：更高层次的抽象来获得（潜在的）性能影响。

标签： c# sql orm

【解决方案1】：

我会尝试根据我的经验回答你所有的问题：

为什么选择 ORM？ ORM 在 Model-First 方法中非常好。当您拥有模型（您的类、对象、实体……）并决定将其保存到某个存储（例如数据库）时。在这里，您采用合适的 ORM 并告诉它“好的，这个类进入这个表”等等。这样可以减少您的开发时间。当然，您在映射上有一些开销。但是，根据我的经验，映射没有性能问题。我在所有其他部分（数据库查询、UI 渲染、WCF、...）都遇到了性能问题，但没有 ORM 映射。因此，ORM 减少了您的开发时间，不会显着地降低性能。
ORM 减少了重复，降低了复杂性并大大增加了开发时间！
用 C# 编写所有内容？部分 - 是的。 ORM 提供强大的映射，因此几乎不可能犯愚蠢的错误，例如比较 int 和 string、将 null 设置为不可为 null 的属性等等。因此，带有 LINQ-provider 的 ORM 可以保护您的代码。
您对性能的担忧被夸大了。当然，EF（或其他 ORM）比手写 SQL 代码要慢。我相信在 99% 的情况下，EF 会让您满意，并且维护此代码要容易得多，它是自我保护和自我解释的。

所以，不要看数字。他们在现实生活中没有任何共同点。如果你需要一些额外的东西，我会尽力解释。

【讨论】：

【解决方案2】：

我想补充一点，Dapper 的比较图表有点误导，Entity Framework 有一个相反的问题 - 启动时间长（图表中的 631 毫秒）。但这只是对数据库的第一次查询，其中模型等是在内存中构建的。

ORM 可以为您做的一件事是编写高度优化的 SQL 查询，而最终您不必担心 SQL 语法以及如何将 POCO 映射到数据库表。像使用任何其他 IEnumeration 一样使用 ORM 对象。

PS：更喜欢这个作为评论，但

【讨论】：