BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Comparing NHibernate and Entity Framework

Comparing NHibernate and Entity Framework

This item in japanese

Lire ce contenu en français

Bookmarks

Developer Ricardo Peres of Portugal has published a seemingly unbiased comparison of the leading .NET ORMs: NHibernate and Entity Framework. While we recommend anyone considering both to read his article, Differences Between NHibernate and Entity Framework, we are going to tough on some of the key differences.

Architecturally, NHibernate is based on Java’s Hibernate ORM. Ricardo writes,

In NHibernate, there is a separation between the Unit of Work and the configuration and model instances. You start off by creating a Configuration object, where you specify all global NHibernate settings such as the database and dialect to use, the batch sizes, the mappings, etc, then you build an ISessionFactory from it. The ISessionFactory holds model and metadata that is tied to a particular database and to the settings that came from the Configuration object, and, there will typically be only one instance of each in a process. Finally, you create instances of ISession from the ISessionFactory, which is the NHibernate representation of the Unit of Work and Identity Map. This is a lightweight object, it basically opens and closes a database connection as required and keeps track of the entities associated with it. ISession objects are cheap to create and dispose, because all of the model complexity is stored in the ISessionFactory and Configuration objects.

Commenter Morten Mertner adds, “NH just never was able to win me over. It has an impressive feature list, but it's not an easy to use product and the API/design smells of its Java inheritance (in the same way that many Java API's are too enterpricey and over-architected; YMMW).”

Entity Framework follows a more traditional .NET design where everything is encapsulated in a single ObjectContext or DbContext. This makes using the object far more straight forward, but the downside is that the “class is therefore not lightweight as its NHibernate counterpart and it is not uncommon to see examples where an instance is cached on a field.”

In regards to mapping, a key difference between NHibernate and Entity Framework is that the former supports XML-based mapping files that are deployed separately. In theory this allows you to use the same object model against different database schemas without recompiling the application. In practice this is rarely used.

There are several areas where the older NHibernate is ahead of Entity Framework. Ricardo offers more detail, but briefly they are:

  • Associations: Both support 1 to 1, 1 to many, and many to many, but NHibernate also supports various order, unordered, and indexed options. It even has an immutable, indexed list.
  • Caching: NHibernate offers a second-level cache with numerous implementations. Entity Framework doesn’t have any built-in support for this, but there are samples for adding second-level caching.
  • ID Generation: NHibernate offers roughly a dozen strategies depending on how you count them. Entity Framework only offers the main three for SQL Server: identity columns, GUIDs, and manually assigned.
  • Events: Entity Framework only has two event-based extension points: ObjectMaterialized and SavingChanges. “NHibernate has a very rich event model, that exposes more than 20 events, either for synchronous pre-execution or asynchronous post-execution”.
  • Cascading: “Both support cascading for collections and associations: when an entity is deleted, their conceptual children are also deleted. NHibernate also offers the possibility to set the foreign key column on children to NULL instead of removing them.”
  • Flushing Changes: NHibernate offers an automatic mode where changes are saved when necessary, such as “if there are dirty instances of an entity type, and a query is performed against this entity type”. FlushMode.Auto is actually the default, but it is not unusual to see auto-flushing being blamed for performance problems.

There a few areas where Entity Framework currently shines over NHibernate such as:

  • Tracking Changes: While both default to change tracking at the unit of work level, Entity Framework also offers self-tracking entities.
  • Integration: Entity Framework of course has close ties with Visual Studio and various ASP.NET and WCF libraries.
  • Documentation: “This is another point where Entity Framework is superior: NHibernate lacks, for starters, an up to date API reference synchronized with its current version.”
  • Queries: Craig writes, “NHibernate is much more feature rich except for one area, Linq support. Because Linq or other query language is the most visible part of the ORM for many users it gives a false impression of capability.”

There are some areas where both could use some improvement such as batching. And neither ORM comes close to SQL Alchemy when it comes to truly leveraging SQL’s advanced features such as common table expressions.

It should be noted that both projects are quite active and improvements to both are seen on a fairly regular basis. So if both meet your minimum requirements, then consider focusing more on the design patterns and philosophy of the libraries than the feature list.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Agree but..

    by Roopesh Shenoy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have used both, and to be honest both seem too bulky. I do agree NHibernate API is too enterprisey, but to be fair, XML Mappings are not really needed right now - we can use FluentNHibernate to have a lot of features that EF has, such as automappings and Fluent interface for defining mappings.

    Some of the benchmarks published do show NHibernate performance to be better than EF in most cases. I think that's a strong point to consider.

  • Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The biggest drawback of putting mapping in the class file is it restricts your application from having multiple views of the same object. I work on enterprise apps, so often times I really need to show multiple views of the same object. With XML mapping, it's trivial to do that.

    Even when I use Hibernate/NHibernate, I prefer to use XML over annotations for that reason. ORM that only allow 1-to-1 mapping between table and object simply make life too painful for applications that allow multiple views of the same objects.

  • Too Enterprisey?

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We have used EF on one project. It seemed to me like it was a whole lot like EJB 1/2. Seems they didn't learn the lessons from Java EE (J2EE at that time).

    I just feel that things in EF are too tightly coupled and there is just too [bad] much magic.

    Also, As others mentioned, it does not seem to be easy to create "view" objects (although i don't do it the way Peter does). Another big stumbling block is that I have not seen any mention of support for EF in Spring.NET.

  • Re: Main strength of xml mapping

    by Roopesh Shenoy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Can you give an example Peter, because I am not sure about what you mean - if you are talking about discriminators, that's possible in fluentnhibernate as well, if about something else, then please explain.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here's an example off the top of my head. Say we have a large object that defines medication and we have a second object that defines the prescription for a specific customer. On a detailed screen, we may want to show both to a clinician. On a summary view (think spreadsheet table), we want to show a join of those two tables.

    With rigid ORM systems, you'd have to get that huge medication object even if you only want to show 2 columns from it. With ORM systems that support views, I can easily create a view and only retrieve the columns I want. The benefit is that I don't need to create a separate object for 1 or more views. With the type of applications I work on, often times the object model has over 1000 objects. If we had to add a view object for every use case, that could balloon the model by 2-3 times.

    On smaller projects with tiny object models that have less than 10 objects, it's probably fine to add a few objects for views, but it's going to be case specific.

  • Re: Main strength of xml mapping

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This kind of stuff is why I don't use ORMs at all. For me, it is much, much easier to just write the SQL I want.

  • Re: Main strength of xml mapping

    by Roopesh Shenoy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    But you can do that with fluentnhibernate as well by mapping the objects to views instead of tables, right?

  • Re: Main strength of xml mapping

    by Frans Bouma,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Any o/r mapper which can do a projection query (read: almost all of them) can do that, it's not something unique for NHibernate, and especially not due to 'xml mappings'.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agree, it's not unique to Hibernate or NHibernate. It's also how developers use the ORM tool. I agree it's not a virtue of xml mappings, since XML can quickly get fugly. It's the ability to have multiple mappings for a single object or table. How a product implements that varies, but having the mapping externalized is a good thing. It avoids having to change class annotations.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I haven't used fluent nhibernate, so I can't say either way. My main point is the benefit of externalizing mapping, to avoid touching the object model more than necessary. If a developer prefers to annotate the class directly, go right ahead. I just prefer to externalize the mapping in the event that I need to do things that are odd or complicated. Though one can argue not supporting complicated mapping has benefits and forces you to keep the object model simpler. By simpler, I don't mean simple. Just relatively "less" complicated, though that is often a subjective judgement.

  • Re: Main strength of xml mapping

    by Roopesh Shenoy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Peter - fluentnhibernate does not depend on class annotations - you can create strongly typed fluent descriptions for your mappings, so in that way, they are quite similar to XML mappings, since they are "external" to the class definition. I think this is possible in Entity framework as well (although I have not used it yet). The benefit against XML mappings is that its strongly typed, can be easily unit tested (using VerifyMappings()), and is quite easy to maintain.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree that strong typing is a valuable feature. Other products have solved this using mapping editors. I'll give you an example.

    When I worked at IBM's Ascential metadata server group, we used a model driven approach to designing the object models in Eclipse. The developer creates the objects in a graphical "UML like" designer. The tool then creates the SQL statements for creating the database tables and the objects. The name of the product has changed several times over the last several years, but the functionality is basically the same.

    The product did lots of additional things like optimizing polymorphic queries using views. Anyone that has tried to use ORM for a complex object model with deep inheritance will know what I mean. Say I have a base object called DomainObject, which a bunch of common temporal attributes. If every object extends it, executing a polymorphic query gets very expensive very quickly.

    An example from auto insurance would be endorsement. I have a base endorsement object, but there could be 500 subclasses. Executing a query for all endorsements on a large commercial auto policy could mean tens of thousands of queries.

    number of subclasses x number of vehicles = number of queries needed to get all endorsements on a policy

    When you add bi-temporal requirement, things get complicated very quickly.

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So Peter, are you saying view objects are good or bad or yes? I can't tell because you say "I can easily create a view and only retrieve the columns I want" and then "If we had to add a view object for every use case".

    Anyway,
    With [N]Hibernate you can:
    1. Create a type-safe class do a "select new" in HQL.
    2. Create a type-save class and do a projection.
    3. Create a db view and map a class to it.
    4. Create an alternative mapping and a matching class.

    I normally do #1 because:
    #2 is more difficult to code,
    #3 means tight coupling and more db objects to manage and more people involved and can confuse people as to which mapping is the Domain vs View, #4 can confuse people as to which mapping is the Domain vs View and could affect caching. Of course #1 means you probably will have a long parameter list in constructors and the query will be HQL (this might not be true for NHibernate and LINQ).

    Of the 4, I would "never" do #3.

    I try to keep view objects to a minimum by creating them when I must and reusing where i can. But I work in a disconnected environment, so i cannot take advantage of lazy loading with "view in session".

    The good news... choice! :)

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Peter, I will make the assumption that the Entity Model designed correctly and say that it sounds like the persistence mechanism (aka RDBMS) was the problem.

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Roopesh, do "model first" in EF and look at the code it generates. Just do something simple.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My bias take, there is no "catch all solution". I've used all 4 techniques on various projects throughout the years. I don't think there is such a thing as "good or bad" when it comes to views. Take my endorsement example, if you were using SqlServer 2008, combining all the columns of all subclasses into 1 view would probably exceed the column limit. With SqlServer 2010, that would be less of an issue. With other databases like DB2 for Z, you'd get similar issues. Of course, one could argue "why do you need 500 endorsement subclasses?"

    I've seen object models with over 2K objects and deep inheritance, so 500 isn't the worst. Object models with 5K objects is pretty common is health care, so it's not all that odd. Sometimes you want to use a view object and other times you want to query the individual objects and transform it to a DTO for UI purposes. Simple ORM work well for small object models that don't have complex views. That's my experience using hibernate, nhibernate, openjpa, ibatis and several other products.

    For me, the bigger issue is making the application maintainable. Sadly, none of the tools really help in that respect. Only realistic solution is to document the heck out of it and make sure it stays in-sync with the actual code. Whether the mapping is externalized or class annotations, model beyond a couple hundred classes become difficult to maintain without good documentation.

    Even products with fancy schema designers end up with the same maintenance issue. Using ORM "can" save development time, but that's just 1 of the many challenges of building maintainable code.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not sure what you mean by RDBMS was the problem. The specific problem I was talking about is running polymorphic queries on large object models. The problem just gets worse when the database has to support bi-temporal features.

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Peter

    Not sure what you mean by RDBMS was the problem. The specific problem I was talking about is running polymorphic queries on large object models. The problem just gets worse when the database has to support bi-temporal features.


    You said "number of subclasses x number of vehicles = number of queries needed to get all endorsements on a policy". That is a RDMBS issue because of how you must store subclasses (unless you do one table per class [structure] with which there could be other issues).

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Peter, I work in healthcare. I know what you mean. I agree there is no perfect solution with Views. My only point was with DB views is that you end up with redundant code and typically app devs don't have access to create/modify them and are generally less readable than the equivalent HQL. Too me, that is bad.

    BTW and oddly enough, one of the biggest EMR vendors does NOT use an RDMBS. :)

    In addition to documentation, good naming is important. I try to use "*View" for non-entity objects. I don't name anything *DTO because I don't use EJB 1/2 ;).

    Also, in my mind ... The way you described DTO - it is a View.

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You said "number of subclasses x number of vehicles = number of queries needed to get all endorsements on a policy". That is a RDMBS issue because of how you must store subclasses (unless you do one table per class [structure] with which there could be other issues).

    I just read your other reply. The problems you state with SQL Server and DB2 and... about exceeding column size is part of my point.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've used multiple products and it doesn't matter if you do 1 table per class heirarchy or 1 table per class. Either way, you eventually run into issues with large object models with more than 1000 objects. With very large object models that have over 4000 objects, polymorphic query is going to be expensive no matter what.

    At IBM metadata server used 1 table per class, but we created multiple views to improve polymorphic queries. So the real answer isn't either 1 table per hierarchy or 1 table per class. Both techniques have to be used for efficient polymorphic queries. Some class hierarchies are going to be simple, while others are nasty hideously painful.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    yeah, I've used data transfer objects (DTO) as views, but also for ETL like operations. I agree it's redundant, but sometimes it just can't be avoided. As much as I like NOT repeating stuff in code, sometimes it's impossible to avoid. Not for technical reasons either. Often it's the product of the schedule, features and functional specs.

    I've done far worse things like use cobol stored procedures with Hibernate. If the DBA forbid dynamic SQL or HQL, you really have no choice but do all sorts of complicated mappings.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I just read your other reply. The problems you state with SQL Server and DB2 and... about exceeding column size is part of my point.


    But all RDB's have limitations. IBM Ascential metadata server worked with sqlserver, oracle and db2. We had to tweak the model compiler to generate different table definitions depending on the target database. My bias take, it's just a hard problem to solve well in a performant and scalable way.

    Even if you stay within the column limit, you still have to take into consideration row limit, partitioning, materialized views vs dynamic views and a bunch of other "stuff".

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Peter, I think we are agreeing. :)

  • Re: Main strength of xml mapping

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This kind of stuff is why I don't use ORMs at all. For me, it is much, much easier to just write the SQL I want.

    I can only comment on my experience. When I so plan SQL, unless I am doing something VERY minor, I end up recreating the wheel and find that using some sort of ORM is better than me rolling my own.

    FYI, you can use SQL and an ORM.

  • Re: Main strength of xml mapping

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, we agree :)

  • Re: Main strength of xml mapping

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This kind of stuff is why I don't use ORMs at all. For me, it is much, much easier to just write the SQL I want.


    That was a reasonable state-of-the-art approach in 1990.

    In 2012, it is usually an anti-pattern in any but the simplest applications.

    Peace,

    Cameron Purdy | Oracle

  • Re: Agree but..

    by Ricardo Peres,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi,
    Like I said in my post, XML mappings are no longer necessary for NHibernate

  • Re: Too Enterprisey?

    by Ricardo Peres,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You probably haven't tested latest Entity Framework Code First! Give it a try and you won't regret it!

  • Re: Main strength of xml mapping

    by Marco Ramirez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agree. The XML mapping instead of annotations means separation of data & metadata. Annotations, in ".NET", "Java", wheter for O.R.M., or other used, seems to me, that "metadata" its overused, or located in the wrong place of code...

  • DDD perspective

    by Vladimir Khorikov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You should not only compare them feature by feature, but also take into account how clean your code will be if you use one ORM or another. Entity Framework vs NHibernate from a DDD perspective

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT