学习 LinqToSql 还是坚持使用 ADO.NET？

Question

学习 LinqToSql 还是坚持使用 ADO.NET？

linqlinq-to-sqlentity-frameworkado.netlinq-to-objects

5

我正在考虑在即将开始的ASP.NET项目中使用哪种技术。假设： - 我将使用Visual Studio 2008 SP1 (.NET Framework 3.5) - 后端将是SQL Server 2005数据库（或可能是2008） - 代码将用C#编写 - 我已经有了LinqToObjects和LinqToXml的经验 - 我也有一些已构建库的ADO.NET经验 - 该项目相对较小 - 网站将包含大约五个屏幕 - 数据库可能会有六七个表格 - 可能会有25-50个活跃用户 - 每天的交易量可能最多只有5-10次 - 最少存储个人数据 - 失败或网站被黑客攻击的后果将是最小的选项： 1.编写存储过程并使用ADO.NET调用它们。完成填充DataSet后，仍然可以使用LinqToObjects。 2.利用我已经掌握的Linq知识来学习LinqToSql。分析：我已经知道如何执行选项1，但我真的想专门使用Linq。选项2的问题在于，根据我读到的所有信息，LinqToSql可能会被弃用，转而使用Entity Framework。问题： 1.如果您已经熟悉其他Linq技术，那么LinqToSql的学习曲线有多陡峭？ 2.考虑到LinqToSql可能不会被微软进一步开发，是否值得投资任何时间来学习它？ 3.了解LinqToSql是否有助于将来理解Entity Framework，还是它们之间的差异太大？ 4.最终，您会推荐我采取哪种选项？更新： marc_s指出，至少在.NET 4.0中，正在进一步开发LinqToSql。链接：http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40。我不知道这是否意味着LinqToSql毕竟有未来，但它确实使学习该技术更具吸引力。我原帖中没有问一个问题，但应该问：Entity Framework的缺陷是否可能影响到这个项目？感谢迄今为止的答案。

进一步分析

以下是基于下面的评论列出的LinqToSql缺点列表：

必须不断更新设计器中的表和项目，以便在更改底层数据库时进行更改。没有办法“刷新”或“同步”它，使其自动识别更改。
版本控制由于设计器未按一致的顺序生成底层文件而变得复杂。
LinqToSql设计器生成与SqlMetal不同的代码。
存在涉及贪婪加载的问题/错误。

其中，第1项是我最关心的问题。即使是在小型项目中，变化也是不可避免的。我记得曾经尝试使用Windows Forms设计器映射到数据库，但它在我的脸上多次爆炸，我放弃了它，转而使用自己编写的ADO.NET帮助程序类。

然而，似乎SqlMetal可能完全能够满足我的需求。我运行一个命令，它从头开始重新生成来自数据库的所有内容，我就完成了。如果我保持我的数据库简单（只有表-没有存储过程、视图或函数），也许SqlMetal就是我所需要的。

- devuxer

1

即使在.NET 4中，Linq-to-SQL也将有所改进，它并没有死亡。请参见http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40。 - marc_s

2

Linq-to-SQL非常容易学习，使用起来真的很有趣 - 不像其他ORM的混乱XML内容，只需要一个漂亮的可视化设计程序; 不像EF那样复杂的映射 - 每个表只需要一个类，并且没有什么意外 - 它只是有效!相比之下，与纯ADO.NET相比，它真的很高效。 - marc_s

1

@Marc：你过于夸大了LinqToSql的作用。DBML文件是XML格式的。我个人认为使用LinqToSql时会有很多负面意外。微软提供的资源相对较少，以推进LinqToSql的发展，他们也这样说了，所以我不确定你为什么会有其他建议？ - Michael Maddox

2

@jfar：稍微搜索一下就可以了，但这里有一些链接：http://www.capprime.com/software_development_weblog/PermaLink,guid,f1a9b52c-b407-4cbb-9197-4bae289ae11d.aspx http://www.capprime.com/software_development_weblog/PermaLink,guid,78e9dd46-b743-4d10-a541-2593354028ba.aspx http://www.west-wind.com/weblog/posts/162336.aspx https://dev59.com/E0fSa4cB1Zd3GeqPA-IP - Michael Maddox

2

@jfar：又一个：http://oakleafblog.blogspot.com/2007/08/eager-loading-appears-to-cause-linq-to.html - Michael Maddox

显示剩余4条评论

5个回答

5

我同意Davide Vosti的观点，但您可能希望考虑其他选项，例如NHibernate（也支持LINQ）。目前的EF版本并不令人印象深刻-它创建了一些非常糟糕的T-SQL语句，执行时间很长。我们目前正在使用EF，但这是我最后一次为.NET 3.5选择EF。我会在.NET 4中再给它一次机会，但除非它有显著的改进，否则我会选择其他选项（而LINQ to SQL不太可能是其中之一）。

- Mark Seemann

3

1.如果你已经熟悉其他Linq技术，那么学习LinqToSql的学习曲线有多陡峭？

对于你所定义的项目范围来说，应该是最小的。做简单的事情非常简单，更高级的概念需要一些了解其底层原理的知识，但同样没有什么惊天动地的东西。

2.考虑到Microsoft可能不会进一步开发LinqToSql，投资学习LinqToSql是否值得？

我认为值得，如果你已经使用Linq技术，那么学习LinqToSql并不难。此外，正如marc_s所指出的，Microsoft将继续支持和开发Linq2Sql。Scott Hanselman在他的Nerd Dinner项目中使用Linq2Sql (http://nerddinner.codeplex.com/)

3.了解LinqToSql能否帮助我有一天理解Entity Framework，或者它们差别太大了？

我使用过很多Linq2Sql，只用了很少一部分的Entity Framework，它们相似但又不同。基础知识大致相同，我没有参与任何超级高级的用例。

4.最终，你会推荐哪个选项适合我的情况？

如果我正在开发像你提出的网站，我会认真考虑Linq2Sql，你可能只需要几个小时就可以让基础工作正常运行，并决定学习曲线是否大于你想处理的范围。（在我看来，我怀疑你会发现这不是问题。）

- Nate

0

1 - 如果您已经熟悉其他Linq技术，那么学习Linq-to-Sql的学习曲线会有多陡峭？我认为您可能掌握了50%的学习曲线，但这只是我的猜测。LinqToSql不仅仅是Linq，还有很多其他方面需要学习。 2 - 学习Linq-To-Sql是否值得投入时间，考虑到它可能不会被微软进一步开发？学习任何ORM都有好处。如果我要学习ORM，LinqToSql可能排在第三或第四位。微软对LinqToSql未来的沟通一直比较模糊，他们显然正在更加努力地推进EntityFramework。微软随时可以改变主意，您必须自己做出决定。 3 - 理解Linq-To-Sql能帮助我理解Entity Framework吗，还是它们太不同了？所有ORM都具有相似的功能，学习任何一个ORM都将帮助您理解其他ORM。LinqToSql实际上与EntityFramework共享许多相同的功能和缺点，因此它们之间的相似之处比您预期的要多得多。话虽如此，我建议先学习EntityFramework再学习LinqToSql。最适合.NET 3.5的ORM在绝大多数情况下显然是NHibernate。NHibernate支持Linq，但它以不同于Microsoft ORM的方式支持它。话虽如此，您没有给出清晰的原因来明确地使NHibernate优于ADO.NET。我不建议在您的情况下使用LinqToSql或EntityFramework。

- Michael Maddox

2

这是一个非常糟糕的答案。NHibernate卓越的特性集仅在高级ORM场景中发挥作用，并且对于第一个ORM支持的项目来说不容易访问。NHibernate的文档比微软产品差得多（尽管这正在改变）。与映射XML文件相比，设计师和“从数据库更新”支持对于初次使用者来说非常棒。我认为你在这里钉了一把锤子。 - John Farrell

我之前没有意识到 Lazy/Eager loading、detached update、支持传统数据库设计以及 model first development（这只是我能想到的一些）都是高级 ORM 场景。我非常不同意你的观点。通常情况下，从一个 ORM 迁移到另一个 ORM 非常困难，所以选择 ORM 时要小心谨慎。 - Michael Maddox

+1 - 在我看来，这绝对不是一个糟糕的答案。谢谢。 - devuxer

1

LinqtoSql中有Lazy/Eager选项，根据问题描述不需要遗留支持，使用5个屏幕-6到7个表也不需要模型优先，如果需要的话可以提供分离更新支持。NHibernate非常棒，但在这种情况下只会解决YAGNI问题。 - John Farrell

0

看一下 Subsonic，它处于 Linq to SQL 和 NHibernate 的易用性的良好中间地带。

使用 subsonic，您可以获得一些 NHibernate 的不错功能，例如基于模型的开发、自动生成数据库架构以及对除 Sql Server 外的其他数据库的支持。

还有一个漂亮的比较页面，列出了这三个 ORM 之间的差异。

- Almond

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，

- Davide Vosti · Accepted Answer

LINQ to Sql如果你已经了解LINQ to Xml或对象（Linq "对象"只是"列表"），它就很简单明了。

微软并没有废弃LINQ to Sql，他们只建议使用EF。它不会被升级。

LINQ to Sql与EF几乎可以看作相似。使用EF可以做更复杂的事情，但在基本层面上几乎是相同的（对于拥有7个表的网站来说不会有任何区别）。

针对您的情况，我建议使用LINQ。它比SP + ADO.NET更快捷、有趣。在现今的时代，使用ORM几乎是一个不错的选择。对我而言，不使用ORM应该是例外情况。