LINQ TO SQL 真的要玩完了？ （翻译的一篇InfoQ的文章）

     收到一篇InfoQ的文章，想起前几天引起争论的一篇评论，于是转载原文并翻译如下。水平有限，出错请海涵并指正。

    原文：http://www.infoq.com/news/2008/11/DLINQ-Future

 

Is LINQ to SQL Truly Dead?

Posted by Jonathan Allen on Nov 01, 2008 06:27 AM

Back in July we reported that LINQ to SQL was transferred to the SQL Data Programmability team. This event raised a lot of concern in the developer community, who worried that work on LINQ to SQL would halt in favor of ADO.NET Entity Framework. A recent announcement by Tim Mallalieu, Program Manager of both LINQ to SQL and Entity Framework, has exasperated those concerns.

 

We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

 

If you read this literally, it merely says that Entity Framework will get more development resources than LINQ to SQL. The problem is Microsoft has a long history of deprecating data access technology without outright saying it is no longer supported.

Before we get too far into the future of LINQ to SQL, let's take a moment to consider its past. In The Origin of LINQ to SQL, Matt Warren describes his project as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready. But that project, along with the larger WinFS project, seems to have gone down the rabbit hole never to return. Needing something, the decision was made to start the process of making LINQ to SQL a shippable product.

Meanwhile, another project was spinning up. ADO.NET Entity Framework was presenting itself as a total solution for mapping between object models and relational databases. Unlike LINQ to SQL, which was specific to SQL Server, this would have a pluggable backend that theoretically could support any database.

The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack. The Entity Framework is being criticized for two reasons.

Developers do not like it because of the complexity. There is far more a developer needs to learn to use it correctly than is needed for LINQ to SQL. Unlike Entity Framework, LINQ to SQL is best used as a simple query and update mechanism without any customization aside from basic table mappings.

Database Vendors do not like it either for an entirely different reason. Entity Framework isn't database specific and offers no way to add database specific features. This is making it hard for vendors like Oracle to get the kind of performance and functionality they need. DataDirect, a leader in high performance database adapters, won't be releasing their Oracle and Sybase drivers until early next year. And Oracle itself won't even discuss a possible release date because they can't get the performance they want without Microsoft adding additional hooks into the framework.

With so much going against it, it is no wonder that teams wanting a lightweight ORM do not see Entity Framework as a viable option. But at the same time, they are worried that LINQ to SQL is already a dead technology.

In a post titled Microsoft kills Linq to SQL, Ayende Rahien writes, 

Doing something like this is spitting in the face of everyone who investment time and money in the Linq to SQL framework, only to be left hanging in the wind, with a dead end software and a costly porting process if they ever want to see new features. Linq to SQL is a decent base level OR/M, and I had had several people tell me that they are willing to accept its current deficiencies, knowing that this will be fixed in the next version. Now, there isn't going to be a next version, and that is really bad for Microsoft reputation.

A commenter on the original story named Jens wrote,

So you guys are actually admitting that Linq To SQL is a dead end? Thanks a lot. Linq To SQL has that 'it just works' attitude to it and is the underpinning of our new project. I coud never ever persuade my boss to go to Entity Framework.

John, another commenter, wants a reasonable migration path between the two and a lightweight version of Entity Framework.

 

A appreciate the desire to have a single 'Linq to DB' framework, but I hope the proposed Entity Framework will offer full Linq To Sql compatibility? Allowing a painless transition to people who don't need all the extra muscle of the framework. I'd rather do OR mapping myself, and use Linq To SQL as a simple way to grab the data only. EF is current a long way from what I'd need!

This sentiment is echoed by several other comments. And that's exactly what Microsoft is doing. In a follow-up post Tim Mallalieu explains,

Over the last few months we have been looking at how to carry forward LINQ to SQL and LINQ to Entities. At first glance one may assert that they are differentiated technologies and can be evolved separately. The problem is that the intersection of capabilities is already quite large and the asks from users of each technology takes the products on a rapid feature convergence path. For example, common asks for LINQ to Entities (that are being delivered with .NET 4.0) are POCO and Lazy Load. Similarly, in the LINQ to SQL side we are being asked to provide new mapping strategies and other features which the EF already has. Additionally there are common asks for new features like UDT’s and better N-Tier support for both stacks. The announcement really centers around the point that, after looking hard at this and triangulating with internal partners and customers, we decided to take the EF forward with regards to the overall convergence effort and over time provide a single solution that can address the various asks.

So there you have it; over the long run LINQ to SQL and LINQ to Entities will merge. In the mean time, development work on LINQ to SQL will not end entirely.

We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.

  LINQ TO SQL 真的要玩完了？

    早在七月我们报道的LINQ TO SQL的项目转到SQL Data Programmability 项目组，就引起了很多来自开发社区认为支持ADO.NET Entity Framework会使得LINQ-TO SQL停止开发的担忧。

    最近，LINQ TO SQL以及Entity Framework的项目组的经理的一项声明，加深了这些忧虑。 他说:

      我们对Entity Framework做了大量的工作，以使在.NET 4.0中其成为推荐的LINQ关系型数据库访问技术。我们也正在倾听顾客对LINQ TO SQL的评价，并一如既往的根据社区的反馈信息对产品进行改进。

    如果你认真的读了上面的话，会明白他的意思仅仅是说Entity Framework将获得比LINQ TO SQL更多的资源。考虑到微软轻视数据库访问技术的传统，不如直接说他将放弃对LINQ TO SQL的支持。

    在我们考虑LINQ to SQL 的前途之前，我们来回顾一下。

    在LINQ to SQL 的起源The Origin of LINQ to SQL， Matt Warren 用了“我们从没想像过的”这个句子来描述这个项目。本质上来说，这只不过是在他们开发出真正的ORM产品之前开发LINQ to SQL 的托词而已。但是LINQ to SQL 项目，看起来跟着随着WINFS项目走上了不归路。微软在不成熟的情况下，草率的做出了把LINQ TO SQL作为一个新功能产品发布的决定。

    同时，另外一个叫做ADO.NET Entity Framework 项目上马。该项目被作为映射从实体数据模型到关系型数据库之间的一个完整的解决方案。而且它可扩展的后端使其理论上讲可以支持任何数据库，不像LINQ to SQL只支持SQL Server。

    因为规模的原因,Entity Framework错过了.NET 3.5和VS2008。不走运的是，它被放在.NET 3.5 SP1这个看起来像一个新的版本而不是一个补丁的补丁发布出来。Entity Framework因为两个原因所被诟病。

    开发人员不喜欢，因为太复杂。从入手难度和功能上讲，Entity Framework远没有LINQ to SQL实惠。在没有额外的个性化映射策略前提下，LINQ to SQL适合被用作简单查询和更新架构，Entity Framework则不行。

    因为另外一个理由，数据库提供商也不喜欢。Entity Framework并不针对特定的数据库而且无法给某种数据库添加额外的功能。使得很难让数据库提供商比如Oracle去获取他们需要的功能。DataDirect，高性能数据库适配器的领头羊，至少明年初都不会发布在Entity Framework与Oracle和SyBase之间驱动程序。Oracle本身也不会讨论莫须有的发布日期，因为它们无法提高数据库的性能，除非微软添加额外的钩子到框架中。

    有这么多的利空消息，毫无疑问，一个希望轻量级ORM的项目组不会把可能把Entity Framework作为一个可行的选择。但是同时，他们也担心LINQ to SQL 是一个将完蛋的技术。

    在一个帖子“微软杀死LINQ to SQL ”上，作者 Ayende Rahien写到：

      那些正在浪费时间和金钱到LINQ to SQL 框架的每个人，将随着这个死去的软件和要花费巨大成本去修改的项目一起，被遗弃在风中。LINQ to SQL 是一个体面的基础级别ORM，也有很多人告诉我他们在知道可能被套在下一个版本的情况下愿意接受它现在的缺点。现在，没有新版本了，这真是有损微软的名声。

    原声明后面还一个叫 Jens的写到：

      你写的这些就是说LINQ to SQL 要完蛋了吗？那谢谢了。LINQ to SQL 起码还在运行，我们的一个新项目底层用的也是它。我完全不可能说服我的老板转向Entity Framework。

    另外一个评论者John希望在二者和轻量级Entity Framework之间有一个合理的集成路线。

      感谢对LINQ to DB 框架的渴求，但是我希望Entity Framework能完全兼容LINQ to SQL。减少对并不需要框架所有额外功能的人转化的成本。我宁愿自己做OR MAPPING ，并使用LINQ to SQL来抓去数据。EF离我的需要还有很远呢。

   这个观点有一定的普遍性。那微软那边的情况怎么样呢，微软到底在做什么呢？

      Tim Mallalieu在后来一个帖子解释道：

       过去几个月，我们一直致力于发扬LINQ to SQL和LINQ to Entities，咋一看，他们是不同的技术，将来应该分开。问题是二者交叉太多，并且对二者的展望也趋于一致。比如说：对LINQ to Entities（将在.NET 4.0中发布）的要求是POCO和延迟载入。类似的，人们也希望LINQ to SQL提供新的映射策略等Entity Framework已经有的功能。此外，人们还希望二者都有UDT和比 N-Tier更多支持的功能。声明确实围绕着这个论点，在内部同事和顾客等多方博弈之下，我们决定采用Entity Framework作为方向来满足各方的要求，并在不久的将来提供一个单独的解决方案来满足各方的要求。

    至此，我们得到什么？总有一天LINQ to SQL 和LINQ TO Entities要合并。同时，LINQ to SQL 的开发也不会结束。

      我们将继续根据顾客的反馈来对DLINQ做一些改进。这个帖子不仅使得将来的产品改革变得明了，也说明了 LINQ to Entities将成为LINQ中推荐的数据库访问技术。