I posted this two days ago, and I got some answers to share. I'm not an expert on DLinq, so this isn't writ in stone.
- DLinq supports lazy loading, but call it delay / deferred loading.
- Not sure why they pick a different term than the standard one in other O/RM.
- It also supports rich eager fetching support, which is really nice. As far as I can tell, the eager fetching support is better than the one NHibernate has, since it seems to support unlimited depth of fetching, while NHibernate supports a single eager fetch of a collection.
- DLinq has support for detached objects, which is really useful the moment your objects are being passed through layers (WS, Remoting, application layers, etc).
- DLinq has support for optimistic concurrency merging. I will need to investigate this further, but it looks to be interesting. There are three ways that DLinq supports merging (OverwriteCurrentValues, KeepCurrentValues, KeepChanges). I guess that there are reasons to want to do one of those, but most of the scenarios that I run into will not work with either of those changes.
- DLinq has object tracking that is invoked on SubmitChanges() to do dirty checking for all the objects that it loaded. This has the potential to cause a performance problem when you have a lot of objects in memory and you modified only a small part of them. A large precentage of the time will be dedicated just for the dirty checking. NHibernate has a similar problem, and it solves this by allowing you to Evict() entities from the session. DLinq's documentation seems to suggest that implementing INotifyPropertyChanging is enough to prevent the expensive dirty checking.
- DLinq has Create / Drop Schema support which is nice if you thinks about your objects first, and schema later. I am still worried that DLinq is too focused on "Start from database, and then build objects", which result in object structure that is less than ideal.
- Luca said something very significant in answer to a question in the session. DLinq is for the simple scenarios. It explicitly not supporting the more complex features that other O/RM does. I assume that this is because those features are comlex by nature, and can cause problems even for experianced developers. The problem is that the complexity is needed to handle complex situtations. And if DLinq will not support it, there is a big hole that you are likely to run into half way into your project. Those features are there because they are needed, not because of love of complexity.
- There doesn't seem to be a lot of places where I can plug my own extensibility classes. I see no way to plug a new collection type into DLinq, the way I did with NHibernate.Generics, or a way to do my own translation from the database to a custom object. NHibernate is simple full of those extensibility seams, and they are extemely useful and needed in many cases.
DLinq seems to an OK O/RM. It has support for the basic features that an O/RM needs, but it doesn't do anything really exciting on the O/RM front.
Linq, on the other hand, is very exciting. I can't wait until I'll be able to build API that makes use of lambda expressions and extention methods. The really nice thing about Linq is that it is not closed to me. I can (and probably will, if Sergey will not do it first :-) ) build a Linq wrapper around NHibernate to give me all the exciting features that DLinq has, while retaining the power and extensibility of NHibernate.
* Real being defined as I can go to customers and tell them that there project's deadline is near enought the time this will be in either go-live license or RTM. And I'm not talking about multi-year projects.