和Google互补的搜索引擎Wolfram|Alpha
Wolfram|Alpha与Google究竟是什么关系，Wolfram|Alpha自己是如何定位的？Wolfram|Alaph在多大程度上是语义网搜索呢？InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。
新闻
LINQ to SQL真的已死？
作者 Jonathan Allen 译者 张逸 发布于 2008年11月6日 下午11时15分
让我们回溯到七月，那时，我们报道了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?
翻译得太差了
发表人
qianping guo
发表于
2008年11月16日 上午8时30分
1 条回复
关注此讨论 回复