DLinq Answers
time to read 6 min | 1093 words

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.

  1. DLinq supports lazy loading, but call it delay / deferred loading.
  1. Not sure why they pick a different term than the standard one in other O/RM.
  2. 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 supports many-to-one and one-to-one associations. As I said, no support for many-to-many associations (which is a pity). I saw no support for dictionaries, which are often used in similar scenarios.
  • Object identity is preserved in the same DataContext (similar to the way NHibernate's Session works).
  • Workable DAL is going to be tricky. I talked with Luca Bolognese about this, and I don't think that there is a good story behind this. Seperating the concerns may be as simple as just writing the entity classes and using the data context as the DAL. Luca's said that this should be safe, since you are working against your objects, and not the database schema. There is a lot of charm in being able to pass a lambda expression to a DAL and let it deal with it. I expect to see this pattern as soon as Linq gets to a real beta cycle*.
  • Caching is done on the DataContext level out of the box. Beyond that, you manage your own.
  • Inheritance is limited to hierarchy per table, using discriminator values.
  • Stored Procedures can be used to get data from the database and turn them to objects. If you are doing filtering on top of that, it will be done in memory. Luca strongly recommends against using stored procedures as an abstraction DAL. I was very happy to hear this, since now I can tell customers that "Microsoft says so." For certain types of customers, this means more than hard numbers.

    • Further observations:

    1. DLinq has support for detached objects, which is really useful the moment your objects are being passed through layers (WS, Remoting, application layers, etc).
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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.

    Summary: 

    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.

    Tweet Share Share 0 comments
    Tags: