EDIT: THIS USED TO BE TRUE, BUT IT'S NOT ANYMORE.
As a person who has used both Entity Framework and NHibernate... I strongly suggest NHibernate. Normally if a FOSS and a MS tech are present, I suggest the MS tech, but I strongly disagree with that for EF. I use EF4 on a day-to-day basis at work, and we have to create a lot of workaround because of EF. Two years ago I used EF for about one year, and then I changed companies, and I've been working with EF for the past year. NHibernate, 2 years ago, is ahead of EF4.
Here's the points they brought up.
Excessive Merge Conflicts With Source Control in Team Environments:
This was partially fixed, from what I hear. They moved the position data for the designer to the bottom of the .edmx, so it's no longer a horrible problem, but still annoying. If me and a co-worker both try modifying the .edmx at the same time, we tend to get horrible merge conflicts because the entire bottom of the file is used to store the position data of the tables in the designer. Our workaround to this problem is to use SVN file locking so we don't double-edit it. Or I ignore locking, and if I get a merge conflict, I just accept their changes and redo my work. Most of my changes aren't so large they take very long to re-do. If this was the only problem, I'd live with it.
If you're using code-first (in EF 4.1) this is a non-issue.
Excess Code Needed to Deal With Lack of Lazy Loading:
They added lazy loading in 4.0.
But it's loading still preforms like a piece of trash. Eager loading is slow, which is a common optimization when you need to speed up your code. I'm running into cases where I have to make 10k+ calls to the database when I'd rather use eager loading. We've timed it, and in many cases it's faster to make multiple database calls (doing myobject.TablenameReference.Load()
in a loop) to a local database then it is to use .Include("Tablename")
. Yes, I know it's very counter-intutivie, but the numbers don't lie. Also, there's no way to specify the fetch stragety, so you can't specify to Join-fetch or not. So I'd say it's improved, but not near as good as NHibernate.
Inordinate focus on the data aspect of entities leads to degraded entity architectures:
Yeah, this is still as true. Again a good example is order.Status. We'd really like that to be an enum, but because of the way EF is designed, we don't have any other choice besides making it a string. They may fix the enum problem in the future, but the lack of control between the how the mapping is done between the table and the object is the true complaint. NHibernate lets you specify methods for doing mappings, to deal with this case.
To extend a point from Craig Stuntz's response, EF is designed around if you want to take the data model, and select directly from it. (IE myModel.Orders.Where(order => order.Status == "NEW").Select(order => order.Customer.FirstName, order=> order.Customer.LastName)
.) EF's model ends up being really hard to write automated tests around if you don't want to hit up the DB. If you want a repository, where you ask for an object that meets some criteria, and it returns the whole object, that's what NHibernate works better at. (IE var order = myOrderRepository.GetByStatus(OrderStatus.New)
).
Another problem I have with EF is it's total lack of extensiblity. One problem we have is we have Enums for order status. But if we do myModel.Orders.Where(order => order.Status == OrderStatus.New.ToString())
, EF will crash on that query because it doesn't know the .ToString() method. It uglifies our code a lot because we can't add support for that. Also there are a lot of internal methods, so we need to cause a odd behavior to happen, we can't do that.
If you're using NHibernate, Linq adds a lot of features to nhibernate that make it much better. Using a conventions-based model, it requires very little code for most of your mappings. If you're using an existing database, Nhibernate lets you specify non-standard conventions to use, and then have them map up, and everything is easily managed. EF 4.0 (and I don't think 4.1) doesn't have support for anything like that.
I hope this helps you out.