Fabrice's weblog

Tools and Source

News

My .NET Toolbox
An error occured. See the script errors signaled by your web browser.
No tools selected yet
.NET tools by SharpToolbox.com

Read sample chapters or buy LINQ in Action now!
Our LINQ book is also available on AMAZON

.NET jobs

Emplois .NET

Tuneo

ASP.NET Hosting transatlantys

Contact

Me

Others

Selected content

Archives

Bye bye DLinq, Hello Linq for Sql and the ADO.NET Entity Framework!

Some of you may have read the documents on ADO.NET 3.0 and the Entity Framework when they were published, before they were promptly removed. The big question since that time has been: What will happen to DLinq in regard to the future of ADO.NET, which seemed to offer the same services and more with a different solution?
Well, Andres Aguiar has the scoop, live from TechEd in Boston: apparently both frameworks will be kept.
OK, it actually happened. We'll have two mapping technologies in .NET v.next.

LinQ for SQL, previously known as DLinQ is the 'simple' mapping technology.
LinQ for Entities, will be on top of the new ADO.NET Entity Framework, and will be the 'complex' (we could say 'real') mapping technology.
What? Two object-relational mapping technologies for .NET from Microsoft? What's the point?! Why not raise ObjectSpaces from the dead while the are at it...

I feel the same as Andres:
I think Microsoft did this for internal politically correctness (they did not want to not to ship any of the frameworks) but I can't see why this is good for the .NET Framework as a whole.
The team that worked on DLinq worked on ObjectSpaces before and killing DLinq after ObjectSpaces may have been to hard for Microsoft's developers after all the years they have spent on these projects.

To me, two solutions mean an excess of one. I don't see how people will be able to choose, and I think one will have to disappear sooner or later...

Cross-posted from http://linqinaction.net

Comments

Mark Kamoski said:

Ug. It is getting worse by the minute. The real sad part is that they had it right with ObjectSpaces. Why they killed that project, God only knows. I am still smarting over that. There are thousands of OR-mapper fans. Hundreds of OR-mappers along the lines of ObjectSpace. ObjectSpaces was, from what I saw, all but done-- at least the basic version of it. What does Microsoft do? They kill it before it is even born. (Sounds like another quite-a-bit-south-of-sane policy that I know.) Anyway, this validates my own personal policy-- "whenever possible, do not try anything Alpha, or Beta, or pre-release". In fact, don't ever read about taht stuff. In fact, I now know that my hesitation to open this article was well-justified. I thought "what's this?... something promising?... or just more rumor?....". No offence to the author, of course-- I do not ever blame the messenger. Anyway, as will all things, just wait for the release. Why? Well, simply because everything else is not reality. --Mark Kamoski
# June 13, 2006 6:27 AM

Eric Newton said:

I disagree with both.

ObjectSpaces would've been perfect back in the 1.0 days, although I cant imagine how well it would've actually worked with everything un-generified.  Although Paul Wilson's ORMapper (modeled as a mirror API) works well in 1.0.

The team that thought up LINQ however, easily eclipsed ObjectSpaces and a DLinq HAD to be borne.  

Linq for Entities will simply be another logical step forward for business-entities, and having Dlinq as a starting point is MUCH easier than having to translate from SqlCommands.
# June 14, 2006 12:36 AM