DLinQ = LinQ for SQL

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.

Now, does this make sense? How will someone decide to use one or the other?

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.

 

2 Comments

  • I also don't understand why they put out 2 different flavors. But I don't know the details of any of the new types, so I can't comment on that (I'm not at teched)

    What it will create though is a lot of confusion for the developer: he has a database to talk to and some code to write: what to use? Linq for Sql or the entity framework?

    Is it even possible to make that decision? Based on the info I have on both frameworks, I don't think it is. So I predict one of the two will never make it to the final release, for the simple fact that whatever you can do with DLinq is also possible with the entity framework.

  • linq is actually the technology that dlinq is build on-top of.

Comments have been disabled for this content.