Bug Vanquisher

14 October 2007

LINQ/Entity Framework vs. nHibernate

Filed under: Dev inside! — Tanveer Badar @ 1:40 PM

To begin with, let me elaborate what nHIbernate is in the first place. nHIbernate is a persistence library written solely for .net framework, modeled after Java’s Hibernate library that provides services to persist .net framework  objects to and from an underlying database, in a very concise manner of speaking.

The framework requires you to map tables to classes which it calls persistent classes or entities. This mapping is done by XML files which map specific columns to properties. Most visible feature is that you never have to write SQL statements in your code. Apart from that you never need to worry about referential integrity anymore because it maps foreign keys pretty efficiently and provides easy access to other tables through property notation.

Microsoft came out very (very, very, very … ad-infinitum) late with a object persistence framework of their own. This framework is the ADO.Net Entity Framework. This framework also provides similar facilities. To say the least, you don’t have to worry about joins and foreign keys ever again (only if the generator tools work correctly).

Entity framework will very heavily compete with nHibernate. Both provides similar services to developers. A developer using either can forget about SQL (after proper entity generation of course) and use object/property syntax to save and load data. But the problems for nHibernate don’t end here.

To add insult to injury, Microsoft will ship LINQ next year with VS 2008. LINQ provides powerful capabilities to write inline queries in HLL like C# and VB. C++/CLI can also benefit but only from LINQ method syntax. LINQ to SQL and LINQ to Entities will make life still easier for developers. While you have to do this in nHIbernate to select all customers who have not performed any transactions yet:

ISession session = factory.OpenSession( );

try
{
return session.CreateCriteria( typeof( Customer ) ).Add( Expression.NotEq( “DebitAccount” , customer ) ).List<Customer>( );
}
finally
{
session.Close( );
}

On the other hand, when you write the same query in C#/LINQ, the syntax is much more like SQL:

var query = from customer in CUstomers
from transaction in Transactions
where customer.Account != transaction.DebitAccount
select customer;

We can clearly see that everyone is going to prefer LINQ/Entity framework dual delights in comparison to nHIbernate.

Of course, Microsoft has the unfair advantage is owning C# compiler, they can make whatever changes they like to the language and be done with it in over two years only. Just to support LINQ they have

  • added anonymous types, I could have written select new { customer.Name }; if I wanted only the names and this would result in a projection when SQL was eventually generated.
  • lambda expressions, when using method syntax I would have written .Where( (customer,transaction)=>customer.Account != transaction.DebitAccount ).
  • extension methods, LINQ can be applied to any thing that implements IEnumerable<T>, this is possible because of public Where( this IEnumerable<T> , Func<bool,T> ).
  • type inference, noticed that var query? Compiler automatically infers the type of query from right hand side. Also (customer,transaction)=>customer.Account!= transaction.DebitAccount translates to a delegate which returns a bool with two unbound parameter types that are resolved at runtime.

nHIbernate (or any other persistence library for that matter) could never hope to compete with Microsoft on account of the lengths they would go to retrofit their languages with query features.

[Edit: (17/06/2009) In retrospect, this post should never have been written in the first place. The more I read about EF, the more incomplete it felt. EF still has to go a long stretch to even hope for any competitive market share, only a microsoft n00b enthusiast would recommend EF in any sensible enterprise level application. There are too many things you cannot do in EF which are lingua franca in hibernate/nHibernate. A dismal failure on microsoft’s part if one may.]

Advertisements

9 Comments »

  1. Not necessarilly true. LINQ is extensible, meaning the nHibernate team could create their own extension, LINQ to nHibernate, and compete just fine.

    Comment by Cepheus — 14 October 2007 @ 7:10 PM

  2. Of course, I forgot that option. But you see, it is the only viable option. They cannot do what Microsoft did because they do not own the language. They can never provide anything like LINQ.
    Putting LINQ aside, Entity SQL looks very similar to nHibernate’s HQL.

    Comment by Tanveer Badar — 14 October 2007 @ 11:21 PM

  3. Entity Framework and LINQ to Entities is just fine. But one thing that Hibernate can do is to map my existing “entities” to a database. With Entity Framework I have to use the generated classes to map to a database, therefore I must refactor entirely my existing applications to use the framework. Can you please post your opinion about this issue?. It’ll really help me.

    Comment by Arturo — 15 February 2008 @ 2:06 AM

  4. I guess you are talking about the hbm (mapping) files.

    Proper documentation for LINQ is yet to be released in Windows SDK, but LINQ does provide a way to specify a mapping file too. I remember reading about it in online MSDN somewhere.

    It is principally a difference of what is default for LINQ vs. nHibernate. LINQ defaults to attributes on generated classes, but can also use a mapping file. nHibernate defaults to mapping files but it can use attributed classes too.

    Comment by Tanveer Badar — 15 February 2008 @ 3:15 PM

  5. Let me offer a model to think about this area which I believe anything else is incredibly dangerous as these issues are not your typical technology decisions.

    Few frame this as it should be framed: A ‘business driven as much as technology’ mandate.

    Indeed we are used to the next great technology and our excitment allowing our minds to skip the ‘why’ completely. We do it like all others but we must be aware of it and correct it.

    ORM is only as valuable as a team then merges the amazing removal of waste (after initial incredible pain mentally as people) into the domain language and expertise of their business.

    So first, the ‘why care’ about ORM. THEN you can think in a useful way on the ‘how to do ORM’ and ‘what are the ‘positive’ factors and deal-breakers when looking at a Candide implementations of the ORM Concept.

    The fact is this: Microsoft has no ORM solution as of 7/23/2008 and it will not happen in the first prod release of what they are calling an ORM solution. It just is not. Their fault here is adding a label incorrectly. I don’t blame them as of course they want the FUD factor to mess with NHibermate, but if I were in their position I would take my licks and postpone the release for a year and fix the problems, no matter how painful for them. Anything else is insulting.

    They do get it!!!!

    This is about market positioning concerns. Just read the ‘in defense of’ comments to the vote of no confidence to see how bad their situation is.

    Linq is a completely different dimension of ‘optimization in developer API to the ORM technology’ but that is just there as a given (or should be assumed to be).

    It is LANGUAGE INTEGRATED in it is just .NET 3.5 as mapped into C#, VB.NET etc.

    .NET 3.5 is not ORM so why do people think Linq is?

    Linq is more about things like functional programming and indeed the key killer applications now include optimizing providers in Linq to SQL for example.

    ANOTHER KEY FALLACY TO OVERCOME:

    Any ORM offering first must meet the ‘software engineering’ test of ORM and then it is a candidate. No vendor bells and whistle matter if you cannot do what I describe below.

    The key discussion then becomes:

    1) Which ORM offering best allows me to seamlessly and maintainable/productive way DO ORM!.

    2) How can I then leverage this pre-req to implement a domain-driven entity service layer with persistent-ignorant entities.

    THE WHY
    ————–

    To allow everyone to speak the same language (Ubiquitous language) and remove layers of non-value added ‘garbage’ like Transact SQL and Data Models as baseline developer thought.

    If a team thinks of the problems in their domain in terms of RDBMS non-OO construct they have failed. Inevitably the ‘entities’ they create are not entities at all but thin layers over their db. For them use things like the ActiveRecord pattern until they can evolve. But they need to KNOW they are not there. This is the issue.

    All this means is we are building ‘single-responsibility classes which are not overloaded with concerns.

    This assumes as well that you are well designed (or designed to baseline expectation).

    If you have no real common design skills at the team level ORM is a silly consideration.

    ORM is not a tool or add-in it’s a change in thought fundamentally. It assumes your already in a design supporting the ubiquitous language mandate.

    So your post will be read as moving them to miss the point perhaps? What do you think?

    This kills 90% of first tries I’ve found in my work. I often get involved after the initial failure when they are smart enough to reach out for help.

    Many are either angry or very happy when I-we clearly inform them that they are not ready for ORM because they lack the architecture or baseline practices to use it in any effective or ‘as intended’ concept.

    For them Linq to SQL is a great option and eventually the design can evolve to allow ORM. I then shift work into that objective.

    SUMMARY

    1) Today Linq must be just assumed. It is also not a relevant ORM decision point.

    2) Next what is the ‘best’ where that is decided on your goals and evolution as an organization.

    3) Most are not ready for ORM and should instead realize the big picture and optimize in other areas that downstream introduce ORM.

    3) As measure by what ORM must do, NHibernate is the only real move to make. Just ensure you abstract it as you would any third-party dependency. People when they get all the above will screw up in coding directly to NHibermate where a system cannot exist with a different ORM without a major rewrite. It’s easy to avoid and is a sign your not ready to start.

    4) By definition those using Entity Framework are missing the point. If they really understood the drivers they would defer ORM all together if Microsoft is a mandate (a horrible constraint where ANY VENDOR must be used, it’s not about Microsoft) .

    5) If indeed they are ready to rock on ORM but forced into Entity Framework they will be forced to fail we assert without creating a lot of code already present in NHibermate for the missing fundamental conceptual ORM baseline.

    6) Instead we recommend:

    a) Use NHibernate but anyone needs to implement via a design abstracting it just like anything else ORM or not

    b) When EF is a candidate, it will be a no-brainer to use it if you want (or not).

    Kind Regards,
    Damon Wilder Carr
    http://blog.domaindotnet.com/

    Comment by Damon Wilder Carr — 23 July 2008 @ 9:55 PM

  6. Thanks for this article :) Now I have a clear image of both solution .

    Comment by simplyclear — 25 December 2008 @ 9:03 PM

  7. The description of these two systems is really shallow. You’ve not hit on deep loads or anything and that is something the entity framework doesn’t do well, nor does it handle relationship well or multiple level joins. Many of the frameworks like LLBLGen, NHibernate, etc offer enterprise needed functionality like that. In addition entity framework is NOT a good ORM for SOA minimal noise systems. Entity framework requires quit a bit of work up for a simple GUID as key, this is a major problem in systems that need to send a batch insert of the primary key item and all associated foreign key items.

    NHibernate and LLBLGen handle it much better with less overhead. So I wouldn’t say there is no competition, there is plenty. Aside from that NHibernate, LLBLGen, .netTiers, and the many others have years of an advantage over Microsoft’s solution. It is nice they’ve thrown their ideas into a product too, but I wouldn’t write off those other frameworks, especially being that ORMs are generally used by the more advanced non-drag and drop programmers that want real control, concurrency, scalability, and other such functionality. Something that entity framework comes up weak in many way.

    As for LINQ you can LINQify any thing you want, but it appears LINQ is munged into the same concept as ORM in this entry, so make sure to differentiate these two things for more clarity.

    Comment by adron — 26 January 2009 @ 11:31 AM

  8. btw – I just re-read my comment and realized I come off rather brash. Please excuse that… I honestly didn’t mean for it to come off that way. I was just wanting to state that more clarity should be given to the differences and don’t overweight Microsoft’s largess, it hasn’t given them the edge in this yet, and I wouldn’t guess they’ll gain it anytime soon considering the response to Entity Framework they’ve received.

    Comment by adron — 26 January 2009 @ 11:32 AM

  9. […]  https://tanveerbadar.wordpress.com/2007/10/14/linqentity-framework-vs-nhibernate/  […]

    Pingback by My initial take on Entity Framework « Priya’s Blog — 17 June 2009 @ 4:40 PM


RSS feed for comments on this post. TrackBack URI

Leave a Reply to My initial take on Entity Framework « Priya’s Blog Cancel reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: