BT

LINQ to SQL, The Next Step

by Jonathan Allen on Dec 04, 2008 |

Despite the numerous problems with Microsoft ORMs and the plethora of alternatives such as LLBLGen, nHibernate, and OpenAccess, many developers are forced to use Microsoft tech because that is why their company or customer wants. And between the two offerings, it seems most developers believe that Entity Framework is not a viable option. So what are they do to?

Steel Price choose ignore the death of Linq to Sql and is going to continuing using it because it works. As for Entity Framework, he writes about its inability to access underlying columns.

I would never, never use an association such as "give me all addresses updated by John". To make these matters worse, I can't even get the Address's CreatedById unless I load the entire Login object and reference it like this: Address.CreatedByLogin.LoginId which sucks when you are programming and creating queries.

Are there ways around this? Sure, but they are all so complex and tedious that using L2E is simply too complex for 80% of my work. In the 20% case where I really do need the extra features complex mapping, I would be using some other tool such as LLBLGen Pro or OpenAccess because it is far easier to work with.

The C# MVP David Hayden echoes the sentiments of many developers, just make LINQ to SQL open source. He goes one step further and suggests that it should be governed in the same way ASP.NET MVC with the community deriving the design.

I highly recommend that Microsoft re-instate the original development team for LINQ To SQL and have them put together a release for .NET 4.0 that is placed on CodePlex as open source. There is no way the ADO.NET Team can do what is right for LINQ To SQL given their obvious bias to the Entity Framework.

I recommend the new team use a similar approach to that of the ASP.NET MVC Team where we get a highly testable, opinionated, lightweight O/R Mapper that has frequent CTP releases with attention to continuous community feedback.

Ian Cooper, another MVP, sees neither LINQ to SQL nor Entity Framework being completely suitable,

Our lack of confidence issue in EF will not be solved by simply removing its competitors. What we need to see is increased understanding of the criticism. But the announcements still fail to point out the areas where LINQ To SQL is a better solution than EF. L2S has many features that EF badly needs such as domain-first support, POCO, performance of generated SQL, lazy loading, etc. Without public acknowledgement of those strengths doubt must remain as to whether or not the ADO.NET understand why LINQ To SQL has such positive support.

Instead of killing LINQ to SQL, he suggests Microsoft acknowledge mistakes were made and start over with something based on the strengths of both.

A better outcome would have seen MS announce a successor to both LINQ To SQL and Entity Framework. Take the feedback from both productsand build something new. Let's call it 'LINQ to Relations' or 'LINQ to RDBMS'. For sure re-use where you can to save cost if you need to, but re-imagine. I do not imagine that the API changes would be any more significant than those that L2S and EF developers will face in the next iteration of your ORM anyway.

[…]

Most of all take Faulkner's advice and be prepared to kill your darlings. Sometimes the features that you have most invested in, are not ones that should make the final cut of the re-imagining.

Then release early, and release often.

Finally, Scott Allen questions the focus on databases in the first place.

The internals of LINQ to SQL could, I think, form the nice foundation for a generic data mapping framework that would be complementary to ORM type frameworks like the Entity Framework. The framework could take out some of the grunt work of object to object mapping, and perhaps through a provider type architecture offer additional mapping capabilities to and from various formats, like XHTML, JSON, CSV. Transforming, massaging, and pushing around data is a fact of life in most large applications and a framework that makes this job easier to implement and test in a uniform manner would be a boon for productivity.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I think you are reversing the logic a bit by David Leon

As an unbiased .NET guy who does not use much ORM in his daily life, I can say a couple of things with integrity. First, I have reviewed the claims made against the Entity Framework, and they aren't really very impressive. Minor quibbles that can be avoided through light organizational work. Rather than saying 'Developers want to keep using nHibrenate because EF doesn't work yet' it would be more honest to say 'Some guys don't want to use EF because they like nHibrenate'. It would also be honest to say 'some guys are trumping up a case against EF because they don't want to be forced to stop using nHibrenate'. An even more honest assessment would be 'Some nHibrenate guys are afraid that their bosses will make them move to EF {just because it is from Microsoft}, so they are cooking up a case against EF'. Before you flame me, just remember that I don't have a dog in this fight. I am just an ordinary developer who does not use ORM.

A list of what L2S can do by John Rusk

I posted a list here of all the things that Linq to SQL can do. It's a long list, particularly because Linq to SQL exposes an API that lets developers add additional features on top of it. (The MetaModel and associated classes).

With all this capability, I can see why so many people are keen to retain L2S.

Re: I think you are reversing the logic a bit by Steve Macdonald

David Leon:

"I am just an ordinary developer who does not use ORM"

Well then, with due respect David, what qualifies you to comment on ORM issues like this one?

I DO use ORM extensively, and right now there is NO WAY I am going to recommend that clients use EF instead of LLBLgen or NHibernate (each has different strengths).

'death' of L2S is exaggerated / misinterpretation by Kristofer Andersson

First of all, the statement from MSFT that everyone interpreted as "Linq-to-SQL is dead" clearly states that "...as of .NET 4.0 the Entity Framework will be our recommended data access solution...".

VS2010 and .net 4.0 will probably be released sometime in 2010, and if the usual "wait until SP1" pattern repeats itself then we can add another 6-12 months before it is in a real-world-development usable state. Even if the intention (and wet dreams) of the DP group is that EF will replace L2S, it is not going to happen anytime soon.

Until 'EF vNext' is released and stable (and assuming EF vNext will really address all the issues that is plaguing users of v1; based on the EFDesign blog this is everything but certain), the only viable OR mapper from Microsoft is L2S. I think it is a stupid move of them to come out with such announcements before they can present an alternative to L2S.

That said, considering Microsoft's track record when it comes to big 'strategic plans', who knows if there will even be an EFv2? Maybe they will do a market survey, get the same results as Scott Hanselman's informal .net survey and simply cut their losses on EF... (Not probable, but it has happened before.)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT