速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

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:155026
用户头像

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

关注

评论

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

Assignment 01

高冰洁

IP 基础知识全家桶,45 张图一套带走

小林coding

计算机网络 计算机基础 IP

面向对象五大基本原则

彭阿三

面向对象设计 面向对象五个基本原则 基本原则

SignalR Core之Hubs基本概念

猫定谔的靴

.net core SignalR realtime Hubs

架构师训练营第一次课程感想小记1

tuuezzy

软件工程 求职 架构师 UML

【JS】给console来的样式

德育处主任

Java html5 大前端 Web console

大家都知道递归,尾递归呢?什么又是尾递归优化?

程序猿石头

架构师训练营第一周学习总结

全力以赴@

平常心平常心

zhoo299

随笔杂谈

小师妹学JavaIO之:MappedByteBuffer多大的文件我都装得下

程序那些事

Java io nio 小师妹 buffer

回忆杀:我的编程能力是如何突飞猛进起来的

程序员小跃

Java android 编程 面向对象思想

五分钟学会Elasticsearch查询代理设计

古月木易

读懂才会用:Redis ZSet 的几种使用场景

小眼睛聊技术

Java redis 学习 架构 后端

编程的未来 Java, C, Go, Swift, Dart? Uncle Bob Martin - The Future of Programming

John(易筋)

Java 敏捷开发 编程的未来 编程简史 Bob大叔

【总结】优秀架构师的职责及综合能力

ERC20 Short Address Attack

程序那些事

区块链 以太坊 Token ERC20 代币

架构师训练营第二周

Melo

Java15都快出来了,你还不会Java8中的Lambda?

Java全栈封神

Java Lambda java8

iPad配置OpenVPN客户端

wong

ipad OpenVPN

终于有一个 Java 可以用的微信机器人了

犀利豆

Java

徒手撸框架--实现IoC

犀利豆

Java spring

浅谈互联网思维和区块链思维

CECBC

区块链思维

徒手撸框架--实现Aop

犀利豆

Java spring

Solidity的Bytecode和Opcode简介

程序那些事

区块链 智能合约 以太坊 Ethereum eth

五分钟学会Elasticsearch查询代理设计

奈学教育

elasticsearch ES

Apache Spark有哪些局限性

奈学教育

Apache Spark

食堂就餐卡系统设计

Apache Spark有哪些局限性

古月木易

spark

ARTS打卡第二周6.1-6.7

我笔盒呢

「编程模型」C++封装资源

顿晓

c++ 封装 资源封装 自动化管理 简化代码

第一周作业一:食堂就餐卡系统设计

DZ

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