我已经成功地编写了自己的 SQL 访问代码，并结合了存储过程和参数化查询以及我编写的一个小包装库，以最大限度地减少 ADO.NET 垃圾。过去，这一切对我来说都非常有效，而且我的工作效率很高。
我正在着手一个新项目——我应该把我的旧学校的东西抛在脑后，深入研究一个基于 ORM 的解决方案吗？（我知道 NHibernate 和 EF 之间存在巨大的高概念差异——我不想在这里讨论。为了争论，我们甚至将 LINQ 与老式替代方案混为一谈。）我正在寻找根据我所知道的（并且非常了解），就 ORM 类型的实际应用提出建议。
老式 ADO.NET 代码还是 ORM？我确定有一条曲线——这条曲线是否有让事情变得有价值的投资回报率？我很焦虑并愿意学习，但确实有截止日期。
当我对代码进行原型设计时，我发现 LINQ to SQL 的速度要快得多。当我现在需要一些东西时，它只会吹走任何其他方法。
但这是有代价的。与手动存储过程相比，LINQ 很慢。特别是如果您不是很小心，因为看似微小的更改可能会突然变成 1+N 查询。
我的建议。首先使用 LINQ to SQL，如果您没有获得所需的性能，然后切换到 procs。
一个很好的问题，但一个非常有争议的话题。
几年前Frans Bouma 的这篇博客文章引用了动态 SQL（暗示 ORM）优于存储过程的优点，引发了激烈的火焰战争。
在蒙特利尔的 DevTeach 上就这个话题进行了精彩的讨论。如果您访问以下 URL：http ://www.dotnetrocks.com/default.aspx?showNum= 240，您将能够听到该领域的两位专家（Ted Neward 和 Oren Eini）讨论每种方法的优缺点. 对于没有真正明确答案的主题，您可能会找到最好的答案。