写点什么

LINQ to SQL 真的已死?

  • 2008-11-06
  • 本文字数:2094 字

    阅读完需:约 7 分钟

让我们回溯到七月,那时,我们报道了 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 的数据访问解决方案。

查看英文原文: Is LINQ to SQL Truly Dead?

2008-11-06 23:155465
用户头像

发布了 109 篇内容, 共 46.2 次阅读, 收获喜欢 14 次。

关注

评论

发布
暂无评论
发现更多内容

996统计

你?

这是一个操作系统,但既不是Windows也不是Linux

LAXCUS分布式操作系统

云计算 分布式操作系统 计算机集群 分布式应用 行列混合存储

探索CPU的调度原理

元闰子

操作系统 CPU调度

一次无脑接口测试导致的无效排查的经历

liuzhen007

1月月更

什么是 Github 的元数据以及如何备份 github 上的数据

汪子熙

GitHub 1月月更

深入解读aws graviton3

三少

云计算架构师

探索OS的内存管理原理

元闰子

操作系统 内存管理

一个cpp协程库的前世今生(十四)信号量与条件变量

SkyFire

c++ cocpp

在一年一度高交会,看城市发展的“AI三部曲”

脑极体

一文看懂椭圆曲线签名算法

Rayjun

区块链 椭圆曲线

设计模式【10】-- 顺便看看享元模式

秦怀杂货店

Java 设计模式 享元模式

架构实战营第 4 期 -- 模块六作业

烈火干柴烛灭田边残月

架构实战营

数据产品经理实战-团队搭建

第519区

团队建设 数据产品经理 数据产品 1月月更

架构训练营 -- 模块六

LJK

#架构训练营

技术走向管理第一站 技术经理

张老蔫

28天写作

模块五

撿破爛ぃ

「架构实战营」

09 Prometheus之可靠性及可扩展性

穿过生命散发芬芳

Prometheus 1月月更

SAP R/3系统的R和3分别代表什么含义,负载均衡的实现原理

汪子熙

负载均衡 abap 1月月更

教程直播第6期 | OceanBase 如何进行 Benchmark 测试及调优

OceanBase 数据库

数据库 直播 OceanBase 社区版

每个人都要会的复盘知识

石云升

复盘 迭代管理 1月月更

2021的科技卦象·坤·5G沃土上万物生长

脑极体

实现DCI架构

元闰子

DDD DCI架构

模块四-考试试卷存储方案

Only

架构师实战营 「架构实战营」

《亚马逊编年史》阅读散记

boshi

读书笔记

从零打造Instagram

俞凡

架构 Instagram 大厂实践

从2021分布式数据库开发者大会里,我们找出了这8个关键词

OceanBase 数据库

OceanBase 开源 OceanBase 社区版

【Spring专场】「AOP容器」不看源码就带你认识核心流程以及运作原理

码界西柚

spring spring 源码 1月月更 Spring原理

一图回顾 2021分布式数据库开发者大会精彩看点

OceanBase 数据库

数据库 OceanBase 社区版 开发者大会

云原生学习总结

好吃不贵

可用性和易用性双重飞跃 | OceanBase社区版3.1.2正式发布

OceanBase 数据库

数据库 OceanBase 社区版 开发者大会

模块四作业

cqyanbo

LINQ to SQL真的已死?_.NET_Jonathan Allen_InfoQ精选文章