4

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

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

老式 ADO.NET 代码还是 ORM?我确定有一条曲线——这条曲线是否有让事情变得有价值的投资回报率?我很焦虑并愿意学习,但确实有截止日期。

4

3 回答 3

2

当我对代码进行原型设计时,我发现 LINQ to SQL 的速度要快得多。当我现在需要一些东西时,它只会吹走任何其他方法。

但这是有代价的。与手动存储过程相比,LINQ 很慢。特别是如果您不是很小心,因为看似微小的更改可能会突然变成 1+N 查询。

我的建议。首先使用 LINQ to SQL,如果您没有获得所需的性能,然后切换到 procs。

于 2008-09-12T21:15:34.857 回答
1

一个很好的问题,但一个非常有争议的话题。

几年前Frans Bouma 的这篇博客文章引用了动态 SQL(暗示 ORM)优于存储过程的优点,引发了激烈的火焰战争。

于 2008-09-12T21:19:30.760 回答
0

在蒙特利尔的 DevTeach 上就这个话题进行了精彩的讨论。如果您访问以下 URL:http ://www.dotnetrocks.com/default.aspx?showNum= 240,您将能够听到该领域的两位专家(Ted Neward 和 Oren Eini)讨论每种方法的优缺点. 对于没有真正明确答案的主题,您可能会找到最好的答案。

于 2008-09-12T21:25:14.927 回答