Compare DLINQ, NHibernate and Typed DataSet

I'm quite confused with the abilities provided by the above three items. Could anyone give me some guidelines in choosing between these items When is the best time in using them



Answer this question

Compare DLINQ, NHibernate and Typed DataSet

  • Ranjesh

    All three provide a way to access data from relational databases but there are important distinctions. First, to be clear, current DLinq bits are a part of a preview - i.e. not for production use unlike typed DataSet. DLinq - now called LINQ to SQL is due to be shipped in the "Orcas" release of Visual Studio and .NET Framework. So all the comments below should be considered in that context:

    LINQ to SQL and nhibernate are both ORMs. Typed DataSet is a veneer over DataSet which is basically a relational cache and hence in a different category. LINQ to SQL and DataSet are both part of future/current Microsoft data access stack nhibernate is not a part of Microsoft's data access story.

    If you are building your object model with your own base class and inheritance hierarchies, you should consider DLinq. It provides a very simple way to map your classes to a database and then retrieve object graphs and save the changes back to the database. It uses language-integrated query features of forthcoming versions of C# or VB.NET to provide a much better querying experience against your database. Out of the box, it will support SQL Server 2000/2005 but will be usable with other databases once providers for those databases are available.

    DataSet shines where you want a relational cache that is disconnected from the data source. It has very strong support for remoting and data binding. Typed DataSet basically provides a typed wrapper around DataSet. DataSet also benefits from existing range of ADO.NET v1/v2 providers that can go against a variety of data sources.

    We are currently looking at going between LINQ to SQL and DataSet - similar to what you can do between DataReader and DataSet.

    Just to be clear, nhibernate is not a part of .NET framework or Visual Studio. Perhaps someone else can offer a fairer comparison.

    Also for full disclosure, I am the program manager for LINQ to SQL (aka DLinq) and have been the PM for DataSet before. So you can say that I am biased in favor of these two technologies :-)



  • nigeldude

    regarding the support on (n)hibernate I guess its mostly based on the huge community they have.
    My best suggestion would be to go here
    http://forum.hibernate.org/
    and decide if that seems like enough support for your needs.

    >>I don't think that many other tools will be in the same ball-park (to coin an americanism)
    that might very well be possible, however that is far from the case right now..
    the dlinq functionallity is not top notch at all compared to the existing mappers out there..
    there is really not a single feature I know of in dlinq that no other mapper can already has.

    But at the time of release it might as you say , be in another ball-park , but it certainly isnt today..

    //Roger


  • clamsy

    As stated in the previous post , NHibernate is not supported by MS.
    However NHibernate is a port of the java framework Hibernate that has been around for ages, so its API and functionallity has been proven to wrok and has evolved over the years.

    DLinq is a new project that has not had the same chanse to evolve since its just a preview.

    There are also some other differences , DLinq uses generics to handle lazyload and such , so your domain classes will be far from POCO and will not be possible to use in any other mapper..

    NHibernate uses the POCO approach and the domain classes are just dumb classes with the standard datatypes , which makes switching mapper very easy , atleast when it comes to reuse your domain model.

    Many also feels that POCO classes are also far more clean than a class cluttered with specific mapper related types and code.

    regarding the linq query support in dlinq, thats just a matter of time before NHibernate also gets it.

    I implemented linq query support for our mapper NPersist in less than one day by just translating the lambda expression trees into our own query language, and im sure the NHibernate guys can do the same.

    so the only real benefit that DLinq has over NHibernate is that it is backed up by MS.

    //Roger


  • Stoober

    It seems like NHibby are already working on Linq integration:

    http://forum.hibernate.org/viewtopic.php t=958233&highlight=linq


  • Timdog68

    Correct me if I am wrong, but it seems that the ADO.NET Entity Framework will be close to NHibernate. It will reproduce the same thing (N)Hibernate does with its HQL (Hibernate Query Language) through eSQL (Entity SQL).
    DLinq uses another approach consisting in generating SQL from Linq queries.

    By the way, what will be the benefits of the Entity Framework compared to what Hibernate already offers Why create one more solution


  • D.Candia

    is that it is backed up by MS

    and therefore has access to (an almost) unlimited supply of support (unlike NHibernate etc.), is properly supported, and doubtless will be; the core of some (if not most given time) of the available mapping/DAL tools etc. Oh, and also has Visual Studio integrated design time debugger visualizers, designers etc. etc.

    I'm not a microsoft employee (or a wanna-be etc.) but given the size of their sales/marketing budgets etc. I don't think that many other tools will be in the same ball-park (to coin an americanism)

    Rgds,

    D



  • Compare DLINQ, NHibernate and Typed DataSet