If you are using or have used Entity Framework (EF), then chances are you know about NHibernate. While EF has been in business for a few years now, it is only in the last couple of years that it has got some serious attention, thanks to the performance improvements brought about in EF 6.x and the implementation of some features that are at the core of any ORM. In spite of the recent popularity of EF, a natural question to ask is why you should be taking a look at NHibernate? Well, for starters, NHibernate is probably the oldest ORM in existence. The NHibernate code base has been used in thousands of production applications over the years and is quite sturdy. However, this sounds very subjective to you, so let me give you a list of features that NHibernate has but EF does not.
NHibernate has a stable and sophisticated support for second-level cache. The caching implementation of NHibernate is supported by more than one caching provider ranging from in-memory hash tables to distributed caching solutions such as NCache.
NHibernate has native support for mapping dictionaries. Dictionary mapping comes in handy in various different situations but one interesting situation that comes to my mind is building a multi-tenant system. In a multi-tenant system, multiple tenants are served from the same instance of the application and their data is stored in a single database instance. If a particular tenant has a requirement that needs to have additional properties on some entity to handle additional data about that entity, then this additional data can be stored in a dictionary of key-value pairs. This dictionary is declared as a property on the entity. NHibernate can then map these dictionaries directly to a suitable table schema.
In situations where you need to update a large number of database records as part of batch jobs, the usual session object of NHibernate may be too slow as it tracks every change made to the entities and enforces all the database relations/constraints before the changes are saved to the database. However, the stateless sessions of NHibernate speed things up manifold at the cost of losing features such as change tracking and in-memory enforcement of database constraints. EF has some support for such a behavior through an extension method called
AsNoTrackingor through specific options in theDbContextConfigurationclass. However, in my opinion, both of these options are not as intuitive as the stateless sessions of NHibernate.NH, in general, supports more number of databases than EF does. EF is built, tested, and most commonly used for MS SQL Server. A lot of people also use it for Oracle, but the level of support for databases such as MySQL, Sybase ASE, PostgreSQL, and DB2 is not at par with that for the other databases. If you use one of these databases, then chances are that you will face fewer problems if you are using NHibernate.
Identity generation is one of the important features offered by an ORM. Every database table must have an identity column that uniquely identifies a particular record from the other records. We skipped this part in the introduction section for the sake of simplicity. Corresponding to the identity column in the database table, you will have a class property that holds the identity value. You can then generate a unique identity value for every new instance of this class or you can ask your ORM to generate one for you. If used wisely, identity generation can save a few database trips and improve performance. A particular identity generation strategy may not work well for all situations, so having more than one strategy always helps. NHibernate comes bundled with several identity generation strategies, while EF is still catching up.
NHibernate's support for managing concurrency is far better. Concurrency is when two sessions (usually representing two different end users connecting to the database) try to update the same database record. The last session to update the record is usually working on a stale copy of data. Data is called stale when there is a latest updated version of the data present in the database than the one that you have loaded in the memory. In such a situation, in the absence of proper checks, it is possible that the session working with stale data ends up overwriting a legitimate record with some old value. NHibernate has at least three different models of concurrency management wherein NHibernate detects updates on stale data, aborts the update, and lets the application know of the same. We are going to look at these concurrency models in one of the upcoming chapters in detail, but it is worth mentioning that EF has a limited support for concurrency and it works most effectively only when used with the MS SQL Server database.
NHibernate supports global filters. Global filters let you define dynamic SQL filters once and apply them to every database query or selectively apply them to some of the database queries. One situation where this feature comes in very handy is when you are working with a multi-tenant database. Another situation that I can think of is when you are storing the localized versions of strings in the database and you filter out the correct version by using a culture filter based on the current thread culture.
NHibernate supports four different mechanisms for querying data. While LINQ is the easiest and is supported by both NHibernate and EF, the other three, namely, HQL, Criteria, and QueryOver, are only available in NHibernate. One of the useful things that you can do with these is the tuning of the final SQL generated for your code. With these different query mechanisms, you get a better control over the final SQL generated. Most DBAs would want this ability.