Recently I blogged about migrating to EF from NHibernate and how easy it is to create fully encapsulated models mapped to EF. In this particular project, migrating was relatively painless, as it was a fairly new schema and quite amenable to code-first mapping in EF. The migration was successful in that I didn’t have to undo it and there were relatively few changes that I had to make to the underlying model.
However, there are still reasons why I’d stick to NHibernate, mainly around missing features that exist in NHibernate but don’t exist (yet) in Entity Framework. How important these features are varies from project to project, so while one project might be best using a micro-ORM, one might be best using NHibernate or EF. My punch list of missing features (so far):
- Unique constraints
- Cascade delete orphan
- One-to-one mapping (because unique constraints)
- Global filters
- Mapping to fields
- Encapsulated collections
- Semantic collections (List, Dictionary etc)
- Custom user types
- Primitive collections
- Immutable/readonly entities
- Computed columns (not defined in SQL server)
- Schema generation
- 2nd-level caching
- Future queries
- Actual client-generated IDs – Comb Guid & HiLo
- Robust support for other DBs
- Session.Load instead of mapping the FK separately
A pretty long list to be sure, but not all of these items carry equal weight on any given project, and many of them are available via workarounds or extensions to EF (like the EntityFramework.Extended project). But what about NHibernate? What does EF have (that’s actually useful) but NHibernate doesn’t?
- Anything moderately interesting with LINQ
Those aren’t small features, so while you might be slightly annoyed by a lack of bidirectional one-to-one mapping, not having async might be a big deal for you.
This is a somewhat hasty list generated from projects in which I’ve actually used these NH features in production, but is certainly not an exhaustive list. Let me know in the comments what I’ve missed!