LINQ to SQL, The Next Step
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.
I think you are reversing the logic a bit
A list of what L2S can do
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
"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
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.)
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014