Since J. Tihon did a great job on explaining EF features, I’ll just list the areas where NHibernate runs circles around EF:
- Caching
- EF has nothing out of the box; there’s just an unsupported sample
- NH has complete caching support, including DB-based invalidation. It’s also extensible and provider-based, meaning it works with different types of local and distributed caches
- Batching
- EF has none
- NH has extensive support for lazy-loading groups of entities or collections at once (in any DB), and persisting changes in the same way (Oracle and SQL Server). There’s also MultiQueries and Future Queries, allowing you to arbitrarily group different queries to be sent in one roundtrip.
- User types
- EF has no extensibility at all. It doesn’t even support Enum properties
- No type mappings are hardcoded in NH. You can extend it to support any value types you can create, modify the way existing types are mapped, etc
- Collection support
- EF supports only simple collections of entities. Many-to-many always uses a composite key
- NH supports collections of entities, value types, component types, and also indexed collections and dictionaries (where both the key and the value can be of any type). Many-to-many collections with their own key are supported (idbag)
- Logging
- EF has no logging out of the box. There’s the same unsupported sample listed above
- NH has extensive logging, allowing you to debug issues easily. It uses log4net by default, but you can use any logging framework you want
- Querying
- EF has LINQ as the main query language. LINQ has a high impedance when mapping to relational databases. EF’s provider does not support using entities as parameters; you always have to use Ids. There’s also a query language that’s poorly documented
- NH has LINQ (not as complete as EF’s, though), HQL, QueryOver and Criteria.
- Event system and interceptors
- EF has almost nothing
- NH has a powerful event system that allows you to extend or replace its behavior at any point of the session lifecyle: loading objects, persisting changes, flushing, etc.
I think extensibility is the main selling point. Every aspect of NH is correctly decoupled from the rest, using interfaces and base clases that you can extend whenever you need to, and exposed in configuration options.
EF follows the usual MS pattern of making things closed by default, and we’ll see what’s extensible later.