LINQ to SQL 真的已死？

让我们回溯到七月，那时，我们报道了LINQ to SQL 被转交到 SQL 数据可编程性团队。这一事件在开发者社区引发了大量的关注，人们担心 LINQ to SQL 会被终止，而转而使用 ADO.NET 实体框架。而在最近，LINQ to SQL 和实体框架团队的程序经理 Tim Mallalieu 的一篇通告，又进一步加剧了事态的发展。

我们正大力投资于实体框架。作为.NET 4.0 的一部分，实体框架是我们推荐的在关系场景中针对 LINQ 的数据访问解决方案。我们聆听了客户关于 LINQ to SQL 的反馈，并将结合我们在社区收到的反馈，继续开发和改善该产品。

如果我们从字面上理解，它仅仅是说实体框架获得了比 LINQ to SQL 更多的开发资源。问题是微软在很长一段时间内都反对数据访问技术，但却绝口不提对此不再进行支持。

在我们展望 LINQ to SQL 的未来之前，先让我们回顾一下历史。谈及LINQ to SQL 的起源，Matt Warren 形容他的项目一直都被“视若无物”。从根本上讲，它只是被当作在真正的 ORM 面世之前，用来帮助人们开发 LINQ 的替代品而已。然而，ORM 项目以及更大一些的 WinFS 项目，就像掉进了兔子洞一般永无止境。此时，总是需要做点什么，因此才决定开始将 LINQ to SQL 作为一个产品推出。

同时，另一个项目也在开发之中。ADO.NET 实体框架其名字本身就说明了它将作为在对象模型和关系数据库之间进行映射的整体解决方案。与 LINQ to SQL 只针对于特定的 SQL Server 不同，它是向后兼容的，可插换的，从理论上讲能够支持所有的数据库。

实体框架的规模导致它错失了.NET 3.5/Visual Studio 2008 的最后期限。很不幸的是，它在最后完成之时被命名为“.NET 3.5 Service Pack 1”，而实际上它更像是一个主要的版本，而不是一个服务包。实体框架被横加指责，基于两个原因。

开发人员不喜欢它，是因为其复杂性。若要使用正确，开发者需要比使用 LINQ to SQL 付出更多的精力。与实体框架不同，LINQ to SQL 最利于进行简单查询和更新机制，除了需要基本的表映射之外，无需任何定制。

数据库供应商不喜欢它，但完全基于不同的原因。实体框架是与数据库无关的，也无法提供增加数据库特性的方法。这对供应商如 Oracle 来说，很难获得他们需要的性能和功能。作为高性能数据库适配器中的佼佼者DataDirect，要到明年早期才会发布他们的 Oracle 和 Sybase 驱动。Oracle 甚至根本不愿谈论可能的发布日期，因为如果微软没有在框架中添加额外的钩子，他们就无法获得需要的性能。

既然有如此多的反对意见，因此团队需要一个轻量级的 ORM，而不是将实体框架看作可选项的做法，也就毫不足怪了。但是，同时他们也担心 LINQ to SQL 已经成为一项已经衰亡的技术。

在名为微软杀死了 Linq to SQL的帖子中，Ayende Rahien 写道：

这种做法简直就是朝着那些为 Linq to SQL 框架投入了大量时间与金钱的人脸上吐口水，将他们晾在风中，如果希望看到新的特性，这条路就是走不通的，也意味着要付出昂贵的移植代价。Linq to SQL 达到了 OR/M 的基准水平，我已经听到有好多人告诉我，如果当前的缺陷能够在下一个版本中得到修复，他们完全可以接受它。现在，可能不会再有下一个版本，这无疑会败坏微软的名声。

在 Original Story 的评论家 Jens 写道：

那么你实际已经承认 Linq To SQL 走向了穷途末路？非常感谢。Linq to SQL 已经“足够用”了，它是我们新项目的支柱。我永远都不会劝说我的老板转而使用实体框架。

另一个评论家 John 则希望在实体框架的轻量级版本与二者之间寻求一个合理的迁移路径。

拥有一个单独的‘LinQ to DB’框架的愿望值得肯定，但我希望实体框架能够完全兼容 LinQ To SQL？ 对那些不需要框架特殊能力的人而言，应该支持轻松快捷的转换方式。我更愿意自己做 OR 映射，并使用 LinQ To SQL 作为抓取数据的简单方法。实体框架对于我的需求来讲，实在是太遥远了。

这种感情得到了其他几个评论的应和。而这正是微软正在做的。在紧跟着的帖子中，Tim Mallalieu 解释道：

在过去几个月，我们一直在研究如何将 LINQ to SQL 升级到 LINQ to Entities 中。从第一印象来看，可以断言他们采用了不同的技术，而且是在单独地发展。问题是他们之间功能的交集相当的大，而每种技术的用户又要求产品实现一条快速集中功能的路子。例如，普遍要求 LINQ to Entities（将在.NET 4.0 中发布）是 POCO 以及实现延迟加载（Lazy Load）。相似的，站在 LINQ to SQL 一方，我们也被询问是否提供实体框架已经存在的新的映射策略和其他特性。此外，他们还普遍要求具有类似 UDT's 的特性，以及更好的支持 N-Tier 模型。通告确实集中了这些观点，并在深思熟虑之后，考虑了内部合作者与客户的利益，我们决定为实体框架提供全面的集中能力，并随着时间的推移，最终提供一个单独的解决方案，以解决各种问题。

所以从长远来看，LINQ to SQL 和 LINQ to Entities 将会合并。也就是说，在 LINQ to SQL 上进行开发工作不会全然终止。

根据客户的反馈，我们会继续对 LINQ to SQL 进行投资。这篇帖子将要阐明的是我们对于未来创新的决心，并说明一个事实，也就是 LINQ to Entities 作为.NET 4.0 的一部分，是我们推荐的在关系场景中针对 LINQ 的数据访问解决方案。