This question is asked to me very often, and I always tried to avoid a direct answer, but still I was asked about it so often that I feel that I simply have to answer. In general, I am more inclined towards NHibernate, so when you read this article, please keep this in mind.
EF 4.0 has fixed a lot of problems that exist in the previous version of EF. Things like transparent
lazy loading ,
POCO classes ,
code only , etc. EF 4.0 is clearly much nicer than EF 1.0.
The problem is that EF is still a very young product. All changes that were added to version 4 only touched the surface. I already wrote about some of my problems with the
POCO model
in EF and
Code Only , so I will not repeat. Judging by the problems I described, the main difficulty is that there is a wall between the community experience and what Microsoft does. Both of these cases show typical problems we encountered in NHibernate and Fluent NHibernate. These issues were addressed and resolved in NHibernate, but appear in EF.
Nevertheless, even ignoring the problems I have considered, there are other signs that NHibernate is a mature product. I understood this when I wrote the
Entity Framework Profiler manual; there are things that you simply cannot do with EF, but which are a natural part of NHibernate.
I will not try to create a list of differences by points. We consider those cases where there are significant differences between the capabilities of NHibernate and EF 4.0. These are mainly differences in the possibilities of fine-tuning what the framework does. Typically, these are settings that allow you to achieve greater system performance without compromising the use of OR / M
')
So, here is a short list:
- Batch writing — NHibernate can be configured to batch write to a database; in the case when you need to execute several commands to write to the database, NHibernate can do this in one call to the database, instead of accessing the database for each command.
- Batch reading / multiple queries / Future functions - NHibernate can do this for one database access, instead of accessing the database for each command.
- Batch loading collections - when you load a collection using lazy loading, NHibernate can find other collections of the same type that have not been loaded, and load all in one call to the database. This is a great way to avoid the need for SELECT N + 1.
- Collections with “lazy loading” (“extra”) - Extra Lazy means that NHibernate adapts to the operations that can be run on the top of the collection. This means that blog.Posts.Count will not force the entire collection to load, but rather will create the expression “select count (*) from the posts where BlogId = 1”, and that the query will also be executed to calculate blog.Posts.Contains (), and the entire collection will not be loaded into memory.
- Collection filters and page collections - this allows you to define additional filters (including pagination!) On the top of your collection, which means that you can easily navigate page by blog.Posts, and you don’t have to load the entire collection into memory .
- Layer 2 Cache - managing the cache is challenging, I’ve already pointed out why this is important , so I’ll skip it this time.
- Fine tuning is what is crucial when you need something a little bit beyond what the framework provides. With NHibernate, in almost all cases, you can improve the existing framework; with EF, you are completely and completely blocked.
- Integration and extensibility - NHibernate has a large number of additional projects, such as NHibernate Search, NHibernate Validator, NHibernate Shards, etc. For EF, such projects not only do not exist, but they cannot be written, because such a possibility is simply not provided for EF.
However, on the other hand:
- for EF 4.0, the existing Linq provider is implemented better than the current version of NHibernate. This is something that NH 3.0 was actively working on to fix this gap.
- EF from Microsoft.
From the translator: I myself am currently involved in a small ASP.NET MVC2 + Entity Framework 1.0 project. With other OR / M did not work, so it became interesting to compare NHibernate vs. Entity Framework. The opinion of those who worked closely with both OR / M (or others) is interesting - did Mr. Oren Eini correctly write everything? Do you have anything to add, correct?