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

【问题标题】：Learn LinqToSql or stick with ADO.NET?学习 LinqToSql 还是坚持使用 ADO.NET？
【发布时间】：2009-12-23 08:59:11
【问题描述】：

我正在讨论为即将到来的 ASP.NET 项目使用什么技术。

假设：

我将使用 Visual Studio 2008 SP1 (.NET Framework 3.5)
后端将是 SQL Server 2005 数据库（或可能是 2008）
代码将用 C# 编写
我已经有使用 LinqToObjects 和 LinqToXml 的经验
我也有使用 ADO.NET 和一些已经构建的库的经验
项目比较小
该网站将包含大约五个屏幕
数据库可能有六七个表
可能会有 25-50 个活跃用户
每天的交易量大概在 5-10 次左右
将存储最少的个人数据
失败或网站被黑客入侵的后果很小

选项：

编写存储过程并使用 ADO.NET 调用它们。填充完DataSet 后，我仍然可以使用 LinqToObjects。
利用我对 Linq 的了解来学习 LinqToSql。

分析：

我已经知道如何执行选项 1，但我真的很想专门使用 Linq。选项 2 的问题在于，根据我所阅读的所有内容，LinqToSql 可能会被弃用，而支持实体框架。

问题：

如果您已经熟悉其他 Linq 技术，LinqToSql 的学习曲线有多陡？
鉴于 LinqToSql 可能不会被 Microsoft 进一步开发，是否值得花时间学习 LinqToSql？
了解 LinqToSql 会帮助我有朝一日了解 Entity Framework，还是它们太不一样了？
最终，您会针对我的情况推荐哪个选项？

更新：

我不希望这在 cmets 中丢失：marc_s 指出 LinqToSql 正在进一步开发，至少从 .NET 4.0 开始。链接：http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40.

我不知道这是否意味着 LinqToSql 有未来，但它确实让学习这项技术更具吸引力。

我在原帖中没有问但应该问的一件事：Entity Framework 中的缺陷是否可能影响这个项目？

感谢到目前为止的回答。

进一步分析

以下是 LinqToSql 缺点的列表，基于以下一些 cmets：

在对基础数据库进行更改时，您必须不断更新设计器中的表和项目。无法“刷新”或“同步”它以自动识别更改。
由于设计者不会以一致的顺序生成基础文件，因此版本控制变得复杂。
LinqToSql 设计器生成的代码与 SqlMetal 不同。
存在涉及急切加载的问题/错误。

其中，第 1 项是我最关心的问题。即使是一个小项目，改变也是不可避免的。我记得有一次尝试使用 Windows 窗体设计器映射到数据库，但它在我面前炸毁了很多次，我放弃了它，转而使用我自己的 ADO.NET 辅助类。

不过，似乎 SqlMetal 可以完美地满足我的需求。我运行一个命令，它从数据库中重新生成所有内容，我完成了。如果我让我的数据库保持简单（只是表——没有存储过程、视图或函数），也许 SqlMetal 就是我所需要的。

【问题讨论】：

它没有死——即使在 .NET 4 中，Linq-to-SQL 也会有所改进。见damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
Linq-to-SQL 非常容易学习并且使用起来非常有趣——不像其他 ORM 那样凌乱的 XML 东西，只是一个不错的可视化设计器；没有像 EF 这样的复杂映射 - 每个表只有一个类，而且没有任何意外 - 它可以正常工作！与直接的 ADO.NET 相比，它非常高效
@Marc：你对 LinqToSql 的推销太过分了。 DBML 文件是 XML。我个人觉得在使用 LinqToSql 的时候会有很多负面的惊喜。微软提供了相当少的资源来推动 LinqToSql 向前发展，他们已经说了这么多，所以我不确定你为什么不建议这样做？
@jfar：谷歌搜索应该可以，但这里有一些：capprime.com/software_development_weblog/…capprime.com/software_development_weblog/…west-wind.com/weblog/posts/162336.aspx stackoverflow.com/questions/956131/…
@jfar：另一个：oakleafblog.blogspot.com/2007/08/…

标签： linq linq-to-sql entity-framework ado.net linq-to-objects

【解决方案1】：

如果您已经了解 LINQ to Xml 或对象（Linq“对象”只是“列表”），那么 LINQ to Sql 非常简单......

微软没有弃用 Linq To Sql，他们只是建议使用 EF。不会升级。

可以看出 Linq To Sql 与 EF 几乎相似。使用 EF，您可以做更复杂的事情，但在基本级别几乎相同（对于您的站点有 7 个表，它没有任何区别）。

对于您的情况，我建议使用 LINQ。它比 SP + ADO.NET 更有趣、更快速。现在使用 ORM 几乎是一个不错的选择。不使用它应该是例外（对我来说）。

【讨论】：

Linq-to-SQL IS 正在 .NET 4 中升级：damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
@Davide Vosti：“现在使用 ORM 几乎是一个不错的选择。”我对此深有感触。现在不使用 ORM 是不可接受的。使用 ORM 可以减少编写基础架构代码的时间，而将更多时间用于增加价值。
IIRC，你也可以在 Linq2Sql 中使用存储过程！

【解决方案2】：

我同意 Davide Vosti 的观点，但您可能需要考虑其他选项，例如 NHibernate（也支持 LINQ）。

EF 的当前版本并不令人印象深刻 - 它创建了一些非常需要很长时间才能执行的讨厌的 T-SQL。

我们目前正在使用 EF，但这是我最后一次为 .NET 3.5 选择 EF。我在 .NET 4 中再给它一次机会，但除非它显着改进，否则我会选择其他选项（LINQ to SQL 不太可能是其中之一）。

【讨论】：

【解决方案3】：

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

对于您定义的项目范围，它应该是最小的。做简单的事情是非常简单的，更高级的概念需要一些关于它如何在幕后工作的知识，但同样，没有什么惊天动地的。

2.是否值得花时间学习 LinqToSql，因为它可能不被微软进一步开发？

我会说，如果您已经使用 Linq 技术，它并不难学会。此外，正如 marc_s 所指出的，微软将继续支持和开发 Linq2Sql。 Scott Hanselman 在他的 Nerd Dinner 项目中使用 Linq2Sql (http://nerddinner.codeplex.com/)

3.了解 LinqToSql 会帮助我有一天了解 Entity Framework 还是它们 > 太不一样了？

我用过很多 Linq2Sql 和很少的 Entity Framework，它们相似但不同。基础基本相同，我没有参与任何超高级用例。

4. 最终，您会针对我的情况推荐哪个选项？

如果我正在开发一个像你提议的那样的网站，我会认真研究 Linq2Sql，你可能会在几个小时内完成基础工作，并在学习曲线比你想要处理的更大时做出决定。（恕我直言，我怀疑你会发现是这种情况。）

【讨论】：

【解决方案4】：

1 - 如果您已经熟悉 Linq-to-Sql 的学习曲线有多陡峭与其他 Linq 技术？

我会说你可能已经解决了 50% 的学习曲线，但它可能或多或少，我只是猜测。 LinqToSql 不仅仅是 Linq，还有很多其他功能。

2 - 是否值得花时间学习 Linq-To-Sql，因为它可能不被微软进一步开发？

学习任何 ORM 都有好处。如果我要学习 ORM，LinqToSql 可能会在我的列表中排名第三或第四。微软关于 LinqToSql 未来的沟通充其量是多云的，他们显然正在为 EntityFramework 的未来付出更多努力。微软总是可以改变他们的想法，你必须自己得出结论。

3 - 了解 Linq-To-Sql 会帮助我有一天了解 Entity Framework 还是他们太不一样了？

所有 ORM 都具有相似的功能，学习任何一种 ORM 都会帮助您了解其他 ORM。 LinqToSql 实际上与 EntityFramework 具有许多相同的特性和缺点，因此它们的相似之处比您预期的要多。也就是说，我建议在 LinqToSql 之前学习 EntityFramework。

4 - 最终，您会针对我的情况推荐哪个选项？

在绝大多数情况下，.NET 3.5 的最佳 ORM 显然是 NHibernate。 NHibernate 支持 Linq，但它支持它的方式与 Microsoft ORM 不同。也就是说，您还没有给出一个明确的理由来让 NHibernate 在您的情况下优于 ADO.NET。对于您的情况，我不会推荐 LinqToSql 或 EntityFramework。

【讨论】：

这是一个糟糕的答案。 NHibernate 的高级功能集仅在高级 ORM 场景中发挥作用，并且对于第一个 ORM 支持的项目来说不容易访问。 NHibernate 的文档比 Microsoft 产品差得多（尽管这正在改变）。与映射 xml 文件相比，设计器和“从数据库更新”支持对于初次使用的用户来说非常棒。我认为你的锤子钉在这里。
我没有意识到 Lazy/Eager 加载、分离更新、对遗留数据库设计的支持和模型优先开发（在我的脑海中）是高级 ORM 场景。我恭敬地，完全不同意你的意见。从一个 ORM 迁移到另一个 ORM 通常非常困难，因此在选择 ORM 时要小心。
+1 - 在我看来，这绝对是不是一个糟糕的答案。谢谢。
Lazy/Eager 在 LinqtoSql 中，基于不需要旧版支持的问题，5 个屏幕 - 6 到 7 个表不需要模型优先，如果需要，可以提供分离更新支持。 NHibernate 很棒，但它只会在这种情况下解决 YAGNI 问题。

【解决方案5】：

看看Subsonic，它在易于使用Linq to SQL 和NHibernate 方面处于一个很好的中间地带。

通过 subsonic，您可以获得 NHibernate 的一些不错的功能，例如模型优先开发、自动数据库模式生成以及对 Sql Server 以外的数据库的支持。

还有一个不错的comparison page，列出了三个ORMS之间的区别

【讨论】：