我已经成功地编写了自己的 SQL 访问代码，结合了存储过程和参数化查询以及我编写的一个小包装库来最大程度地减少 ADO.NET 垃圾。过去这一切对我来说都非常有效，并且我的工作效率非常高。
我正在着手一个新项目——我应该把旧学校的东西抛在脑后，深入研究基于 ORM 的解决方案吗？ (我知道 NHibernate 和 EF 之间存在巨大的高概念差异——我不想在这里讨论这一点。为了争论起见，我们甚至可以将 LINQ 与老式的替代方案混为一谈。)根据我所知道的(并且非常了解)关于 ORM 类型内容的实际应用的建议。
老式的 ADO.NET 代码还是 ORM？我确信存在一条曲线——这条曲线是否具有使事情有值(value)的投资返回率？我很渴望并且愿意学习，但确实有一个截止日期。
最佳答案
我发现在进行代码原型(prototype)设计时，LINQ to SQL 速度要快得多。当我现在需要某些东西时，它只会打败任何其他方法。
但是这是有代价的。与手动存储过程相比，LINQ 速度较慢。特别是如果您不太小心的话，因为看似微小的更改可能会突然变成 1+N 次查询。
我的推荐。首先使用 LINQ to SQL，如果没有获得所需的性能，则切换到 procs。
关于orm - 老式 SQL DB 访问与 ORM(NHibernate、EF 等)。谁赢？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59972/