Linq is Really Cool -- But DLinq is a Big Mess
First, let me be very clear -- Linq is a very significant improvement in being able to query structures in a strongly typed manner with both intellisense and compile-time checking. Even better is that it looks like Sql, which is something I've long pushed as being simpler for most people to use than yet another query language, but this is old news to anyone familiar with C-Omega. But Linq by itself only knows how to work with in-memory structures -- in other words, on its own it doesn't know how to interoperate with your other data stores like relational databases and Xml documents.
So that's where DLinq and XLinq come in -- they are essentially extensions that allow you to use Linq to work with relational databases using DLinq and Xml documents using XLinq. XLinq seems to be well received so far, although it looks like it expects you to know far too much Xml in my opinion, unlike my open-source XmlDbClient that allows you to use basic Sql with Xml documents. But DLinq is already getting mixed reviews -- it seems that those that aren't using O/R Mappers think its a big improvement, while those familiar with O/R Mappers, including myself, find it to be the wrong solution.
What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server!
By the way, I've looked under the covers using Reflector, and while it may be theoretically possible that they can remedy this before their eventual release, its also pretty clear that they haven't thought about this. This might be understandable given that this is an early technology preview if it wasn't the third time that MS has previewed an O/R Mapper and been roundly criticized for not supporting other databases. Yes, this is the third time -- their was an early version of ObjectSpaces in the original .NET v1.0 preview at the PDC in 2000, and then their was the major rewrite in the early versions of .NET v2.0 -- so this is their third attempt.
I also believe that while Linq is very easy to use, DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table<Customer> type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to?
Similarly, what if all I want to do is to get a list of all my customers -- why should I have to say "from c in db.Customers select c" when I could just "from Customers" or have a strongly typed Get accessor? My point is that while Linq really is great, you shouldn't be required to write out all of your sql statements for the simple cases after you've gone to all this trouble to mark everything with attributes. Instead Linq should be reserved as the query language for the cases where you need more, and then the fact that it looks much like Sql will be its strength -- but there is no reason why it should be required for the many common simple cases.
Now I've also seen some question whether there is support for persistence and/or stored procs, but a quick look through the docs make it quite clear that both are supported so that isn't an issue. That said, for MS pushing stored procs so heavily, they haven't really thought out how to support stored procs very well for persistence -- again this wouldn't be a big issue if this wasn't their third attempt. So you have to write your own insert, update, and delete methods, mark them with the appropriate attributes, and supply all the logic, including the stored proc name and parameters, in your own code -- not really O/R Mapping as I know it.
And then there are some of the other minor issues which may change as DLinq develops, but again keep in mind that this is NOT a first attempt, so it begs the question of what MS learned from their other attempts -- and all our previous feedback. There's no server-side paging (nor is there in ADO.NET since that was removed), there's no many-to-many relationship yet, and so far there's no support for inheritance and its not clear if distributed apps have been considered. Finally, we were told that ObjectSpaces was delayed so it could be synced with WinFS, but I fail to see any integration with WinFS or OPath at all -- so I wonder if anyone is in charge?
Oh one last thing, since I've already been asked this by several people -- should O/R Mapper vendors be scared, and in particular should I be scared about my ORMapper that was based on ObjectSpaces? If I were to answer this purely from a logical feature-by-feature comparison approach, then the answer is obvious that O/R Mapper vendors have nothing to fear, nor does my own ORMapper. But the problem in the Microsoft world, unlike the Java and open-source worlds, is that 99% of the developers never use anything except what MS gives them, and while this may give developers a taste of O/R Mappers, its also unfortunately going to leave a very poor taste.