传统的SQL方法VS ORM

Question

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

1. https://github.com/StackExchange/dapper-dot-net

2. http://www.dontpaniclabs.com/blog/post/2014/05/01/speed-comparison-dapper-vs-entity-framework/

3. ORM vs traditional database query, which are their fields?

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

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

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

请回答我的问题并告诉我是否需要进行任何编辑。

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

提前致谢。

Answer 1

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

1. 为什么选择ORM？ ORM在Model-First方法中非常出色。当您拥有模型（您的类，对象，实体......）并决定将其保存到某个存储（例如DB）时。在这里你采取合适的ORM并告诉它＆＃34;好的，这个班级去了这个表＆＃34;等等。这样可以缩短您的开发时间。当然，你在映射上有一些开销。但是，根据我的经验，我没有映射的性能问题。我在所有其他部分（数据库查询，UI渲染，WCF，...）中遇到了性能问题，但没有ORM映射。因此，ORM会缩短您的开发时间，微不足道降低性能。

2. ORM减少重复，降低复杂性并大大增加开发时间！

3. 用C＃编写所有内容？部分 - 是的。 ORM提供了强大的映射，因此几乎不可能犯愚蠢的错误，例如比较int和string，将null设置为不可空的属性等等。因此，ORM与LINQ-provider可以保护您的代码。

4. 您对性能的担忧被夸大了。当然，EF（或其他ORM）比手写的SQL代码慢。我相信，在99％的情况下，EF会让您满意并且维护此代码更容易，它可以自我保护和自我解释。

所以，不要看数字。他们与现实生活中没有任何共同之处。 如果您需要一些额外的，我会尝试解释。

Answer 2

我想补充一点，Dapper的比较图表有点误导，实体框架有一个反对 - 一个很长的启动时间（图表中的631ms）。但这只是针对数据库的第一个查询，其中模型和内存都构建在内存中。

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

PS：更喜欢这个评论但＆lt; 50代表：（