现在跳入 LINQ to SQL 是不是一个坏主意？答案

【问题标题】：Is it a bad idea to jump into LINQ to SQL now?现在跳入 LINQ to SQL 是不是一个坏主意？
【发布时间】：2010-12-03 13:57:56
【问题描述】：

到目前为止，我一直在使用 ADO.NET 来支持 LINQ to SQL（或实体）。我正在开始一个应该很小的新项目，至少一开始是这样，但我希望有空间来扩展。

我觉得现在是进入 LINQ 的好时机。我已经避免了很长一段时间。但是，我担心 LINQ to SQL 的当前方向。我听说 LINQ to Entities 将在未来成为 MS 的首选数据访问。我宁愿不进入 LINQ to Entities，因为：1.）很可能是一个更陡峭的学习曲线，我现在不想投入其中（已经忙于学习 MVC）和 2.）我听说它还没有准备好黄金时段。

我担心的是 - 如果我现在使用 LINQ to SQL 开始一个项目，我可以轻松地将它升级到 LINQ to Entities 吗？

【问题讨论】：

标签： .net linq-to-sql entity-framework orm linq-to-entities

【解决方案1】：

Microsoft 发表声明称 LINQ to SQL 已达到其生命周期，将不再对其提供任何重大改进。查看他们的官方糖衣声明here。实体框架将取而代之。

Here is the MSDN article 关于如何将 LINQ to SQL 项目移植到实体框架。

【讨论】：

他们不会改进它，但他们也不会把它拿走。事实上，Windows 窗体也是如此，这并不意味着你不应该使用它。
Winforms 在 WPF 占据统治地位之前有机会成熟。另一方面，LINQ to SQL 仍然相对较新。
但这是否意味着您不应该再使用它了？现在有效的东西将来会继续有效，虽然 MS 不会向它添加新功能，但它仍然会在修复方面支持它（我相信 .NET 4.0 会提供一些修复）。
我从未声称 Beavis 应该不使用 LINQ to SQL。我只是陈述事实。当然，他们仍然保留 LINQ to SQL。但是，如果 LINQ to SQL 和 Entity Framework 是同一问题的解决方案，并且 MS 发表声明说他们将停止在一个平台上进行开发以支持另一个平台，那么推测幸存的技术是更明智的选择并非没有道理。我喜欢 LINQ to SQL 并且我已经使用过它，但我认为（纯属猜测）它将成为微软 ORM 解决方案的红发继子。
这与是否会出现任何“重大改进”无关。这是关于为正确的工作选择正确的工具。我听说轮子已经有一段时间没有任何重大改进了！事实是 L2S 很可能会毫不费力地将 OP 带到他要去的地方。没有学习曲线，没有投资。如果项目要在 4.0 之前发布，并且您只需要支持 SQL Server，我会选择 L2S。如果你稍微小心一点，如果 MS 决定神奇地让你的工作 L2S 代码停止工作，你可以用最小的影响替换你的 DAL...

【解决方案2】：

LINQ to Entities 已准备好迎接黄金时段，而且学习起来不一定要难得多。但是，LINQ to SQL 也很好，您将学到很多东西，这些知识在您前进的过程中仍然有用。

简而言之，选择最适合项目的。如果 SQL Server 是并且将继续是 DB 平台，并且如果不需要重新映射表或其他复杂的技巧，那么 LINQ to SQL 将让您非常快速地到达那里。效率也很高。

【讨论】：

LINQ to SQL 也是一个不错的选择，如果您喜欢在每次更改数据库时不经意地重建 .dbml 文件。
@James Jones 如果您使用的是 PLINQO 之类的东西，则不会
....或huagati.com/dbmltools - 它允许您使用开箱即用的 L2S 设计器，同时添加真正的“仅更改”同步、命名约定、Xml doc cmets、SQL-DDL从 L2S 模型等生成差异脚本。
L2E擅长的东西有一大堆，但是在起跑方面，L2S基本没有学习时间。您当然可以稍后将您的项目升级到 L2E。如果您在应用存储库模式时很小心，那么切换 O/RM 框架非常简单。
因为使用 3rd 方实用程序修补 LINQ to SQL 的漏洞正是我想要的 ORM 解决方案。这就是我所说的那种东西。但是，嘿，如果你不介意这些事情，无论如何......我不会阻止你的。

【解决方案3】：

如果您的应用要在 .net 4.0 SP1 可用之前投入生产，请选择 L2S。 Linq-to-SQL 是稳定的，它不会很快消失，它会生成很棒的 SQL。 EF v1 没有。时期。如果您想了解更多关于 EFv1 儿童疾病的信息，请查看MSDN EF forum。

EFv2 能否胜任这项任务还有待观察；我只使用了 beta 1，它没有一些据说更高版本的改进。

“L2S vs EF”这个话题已经被讨论过无数次了，看看：
Is LINQ to SQL Dead or Alive?

...就我个人而言，我认为 Anders Hejlsberg 对 Redmond Developer News 的声明已经足够清楚了。 “LINQ to SQL 没有死。我可以向你保证，它没有死。什么都不会消失。我们从未这样做过，也永远不会这样做，”他说。

http://reddevnews.com/blogs/desmond-file/2008/12/digital-darwinism.aspx

【讨论】：

【解决方案4】：

那些说 LinqToSql 学习曲线最短的人并不是完全诚实的。 ADO.NET 有一个重要的学习曲线。任何 ORM 都有显着的学习曲线。一旦你使用了一个 ORM，再选择另一个 ORM 并不难。一旦你构建了自己的 ORM（为了好玩，不要真的去做），你就会真正了解发生了什么。

Linq（我不是在谈论 LinqToSql）是一项很棒的技术，您不能将 Linq 与 ADO.NET 一起使用，您需要像 ORM 这样的东西。

出于多种原因（Linq 是其中一个更强大的原因，ORM 成熟度是另一个原因），现在是从 ADO.NET 迁移到 ORM 的好时机。

据我所见，将项目从一个 ORM“升级”到另一个（无论哪个 ORM 都无关紧要）总是很困难，除非您真的知道自己在做什么，并保持您的 ORM 与所有事物的松散耦合尽量不要。

我会提防 LinqToSql 和 EntityFramework（又名 LinqToEntities）。它们都缺少很多您在“现实世界”中可能需要的功能。两者都不是成熟的或经过验证的（正如您在此问题的答案中看到的分歧有助于显示）。

.NET 领域有成熟的、经过验证的 ORM，现在不难确定哪个是主导。

【讨论】：

此答案中的实体框架批评与 EF 1.0/3.5 有关。 EF 4 作为一个 ORM 基本上就可以了。

【解决方案5】：

LINQ to SQL 可能针对 SQL 服务器进行了优化，它可能比实体框架更适合您的问题。

但是，从长远来看，您必须考虑您的应用程序的预期寿命以及“升级”的成本是多少。

【讨论】：

【解决方案6】：

我已经避开了 Microsoft ORM，我很高兴我有。炒作->接受->意识到弱点和缺陷->生命结束，重新开始。

不要误会我的意思，我是 .Net 的忠实粉丝，而不是 Microsoft ORM。有更好的解决方案。

我知道这只是意见，但我提供它是为了它的价值。

【讨论】：