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.