Are you sure you want to finish playing with the LINQ to SQL statements? (An infoq Article translated)

I have received an article from infoq.ArticleThink of a comment that caused debate a few days ago, so I reprinted the original article and translated it as follows. The level is limited. Please correct haihan for an error.

Original article: http://www.infoq.com/news/2008/11/DLINQ-Future

Is LINQ to SQL truly dead?

PostedJonathan AllenOn Nov 01,200 8 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 wocould 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 re making significant investors in the Entity Framework such that as. net 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. we are listening to mers MERs 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. "essential, 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 demo-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 wowould have a pluggable backend that theoretically cocould support any database.

The scale of Entity Framework caused it to miss. 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 mechanisms 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 investors 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 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. 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 MERs, 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 varous 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. net 4.0, LINQ to entities will be the recommended data access solution for LINQ to relational scenarios.

Are you sure you want to finish playing with the LINQ to SQL statements?

As early as July, we reportedLINQ to SQLProjectSQL data programmabilityThe project team has caused many developersCommunitySupportedADO. NET Entity FrameworkWill makeSQL LINQ-TOConcerns about stopping development.

Recently, a statement by the managers of the projects of the LINQ to SQL and Entity Framework deepened these concerns. He said:

We have done a lot of work on the Entity Framework to make it a recommended Technology for accessing the LINQ relational database in. Net 4.0. We are also listening to the customer's comments on LINQ to SQL, and continue to improve our products based on the feedback from the community.

If you read the above carefully, you will understand that it means that the Entity Framework will get more resources than the LINQ to SQL. Considering Microsoft's contempt for the tradition of database access technology, it is better to say that it will give up its support for LINQ to SQL.

When we considerLINQ to SQLLet's review the future.

InLINQ to SQLOriginThe origin of LINQ to SQL,Matt WarrenI used the sentence "we never imagined" to describe this project. In essence, this is only when they developORMDeveloped beforeLINQ to SQL. HoweverLINQ to SQLProject, it seems to followWinfsThe project is on the road. When Microsoft was not mature, it rashly put forwardLINQ to SQLAs a new function product release decision.

In additionADO. NET Entity FrameworkProject. This project is used as a complete solution for ing from the Entity Data Model to the relational database. And its scalable backend enables it to theoretically support any database, unlikeLINQ to SQLOnly supportedSQL Server.

Due to the scale, Entity Framework missed. Net 3.5 and vs2008. Unfortunately, it is put in. Net 3.5 SP1, which looks like a new version instead of a patch released. Entity Framework has been criticized for two reasons.

Developers do not like it because it is too complicated. Starting with the difficulty and function,Entity FrameworkFar fromLINQ to SQLBenefits. Without additional personalized ing policies,LINQ to SQLSuitable for simple query and update architecture,Entity FrameworkNo.

For another reason, database providers do not like it either.Entity FrameworkIt is not applicable to specific databases and cannot add additional features to a database. Makes it difficult for database providers suchOracleTo obtain the functions they need.DataDirectThe leader in high-performance database adapters will not be released at least early next yearEntity FrameworkAndDriver between Oracle and SybaseProgram. Oracle itself won't discuss any release dates that may not be discussed, because they won't improve database performance unless Microsoft adds additional hooks to the framework.

With so many blank messages, there is no doubt that a project team that wants a lightweight ORM will not regard Entity Framework as a feasible option. But at the same time, they are also worried that LINQ to SQL is a final technology.

In a post, "Microsoft kills", AuthorAyende rahienWrite:

Those are wasting time and moneyLINQ to SQLEveryone in the framework will be abandoned in the wind along with the dead software and the project that will take significant cost to modify.LINQ to SQLIs an individual basic levelORMAnd many people tell me that they are willing to accept its current shortcomings when they know that it may be applied in the next version. Now, no new version is available, which is detrimental to Microsoft's reputation.

The original declaration is followed by a write called JENS:

What you wrote isLINQ to SQLAre you finished? Thank you.LINQ to SQLAt least it is still running. It is also used at the bottom of a new project. I cannot convince my boss to turnEntity Framework.

Another reviewer John wants a reasonable integration path between the two and the lightweight Entity Framework.

ThanksLINQ to DBFramework, but I hopeEntity FrameworkFully compatibleLINQ to SQL. Reduce the cost of converting people who do not need all the additional functions of the framework. I would rather do it myselfOr Mapping, And useLINQ to SQLTo capture data.EFIt's still far from my needs.

This point of view is universal. What is the situation at Microsoft? What is Microsoft doing?

Tim mallalieu explained in a later post:

Over the past few months, we have been committedLINQ to SQLAndLINQ to entitiesThey are different technologies and should be separated in the future. The problem is that there are too many intersections between the two, and the outlook for the two is also consistent. For exampleLINQ to entities(. Net 4.0Released) is requiredPocoAnd delayed loading. Similarly, people wantLINQ to SQLProvides New ing policiesEntity FrameworkExisting features. In addition, people want both of them to haveUDTAnd RatioN-tierMore supported features. The statement really revolves around this argument. We decided to adoptEntity FrameworkAs a direction to meet the requirements of all Parties, and provide a separate solution to meet the requirements of all parties in the near future.

So far, what do we get? One day, the combination of LINQ to SQL and LINQ to entities will begin. At the same time, the development of LINQ to SQL will not end.

we will continue to improve dlinq based on customer feedback.. This post not only makes the future product reform clearer, it also shows that LINQ to entities will become the database recommended in LINQ access technology.