老式 SQL DB 访问与 ORM（NHibernate、EF 等）。谁赢？

Question

我已经成功地编写了自己的 SQL 访问代码，结合了存储过程和参数化查询以及我编写的一个小包装库来最大程度地减少 ADO.NET 垃圾。过去这一切对我来说都非常有效，并且我的工作效率非常高。

我正在着手一个新项目——我应该把旧学校的东西抛在脑后，深入研究基于 ORM 的解决方案吗？（我知道 NHibernate 和 EF 之间存在巨大的高概念差异——我不想在这里讨论这个问题。为了便于讨论，我们甚至可以将 LINQ 与老式替代方案混为一谈。）我正在根据我所知道的（并且非常了解）寻找有关 ORM 类型内容的实际应用的建议。

老派的 ADO.NET 代码还是 ORM？我确信存在一条曲线——这条曲线是否具有使事情有价值的投资回报率？我很焦虑并且愿意学习，但确实有一个截止日期。

Answer 1

这是一个好问题，但却是一个非常有争议的话题。

这篇博文来自 Frans Bouma 几年前，引用动态 SQL（即 ORM）相对于存储过程的优点引发了相当激烈的争论。

Answer 2

我发现当我制作代码原型时，LINQ to SQL 的速度要快得多。当我现在需要一些东西时，它只会打败任何其他方法。

但这是有代价的。与手动存储过程相比，LINQ 速度较慢。特别是如果您不太小心的话，因为看似微小的更改可能会突然导致一次查询变成 1+N 次查询。

我的推荐。首先使用 LINQ to SQL，如果没有获得所需的性能，则切换到 procs。

Answer 3

在蒙特利尔的 DevTeach 上对此主题进行了热烈的讨论。如果您访问此网址： http://www.dotnetrocks.com/default.aspx?showNum=240 您将能够听到该领域的两位专家（Ted Neward 和 Oren Eini）讨论每种方法的优缺点。对于没有真正明确答案的主题，这可能是您会找到的最佳答案。