MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)

Question

I just read this article about the Entity Framework 4 (actually version 2).

Entity Framework seems to offer a huge improvement over its first release. Thus, I have never ever used EF in any project, since I think EF is not mature enough in comparison to NHibernate.

NHibernate and its current contributions of FluentNHibernate and Linq for NHibernate by Ayende Rahien

My feeling is that Microsoft is solely trying to gain terrain it has lost in favor of NHibernate when the 2nd version of NHibernate came out. Nevertheless, my concerns are the followings (not in particular order):

• Will EF4 tend to be less XML-verbose?
• Will EF4 be compatible with underlying datastores other than just SQL Server?
• What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?

NHibernate is a great tool, I guess everyone agrees. Due to its predecessor Hibernate, we may easily find documentions and tutorials and sample applications to get acquainted with it. This is not the case for FluentNHibernate. Particularly as per the project I'm working on right now which demands that I investigate further about NHibernate and its options (FluentNHibernate for instance) in order to document the rules of usage and the best practices of NHibernate and FluentNHibernate technology. Thus, being handcuffed with VB.NET, being a C-Style developer, I can't find some syntax equivalencies in VB.NET for the examples provided, though I made my way so far.

I do believe that NHibernate is a best choice, but as a software consultant, I can't (don't want to) miss important technology changes, improvements and evolution.

Despite the bad comments I read about EF1, EF4 seems to be very promising. What you all think about both NHibernate and Entity Framework avenues? As for me, I am becoming puzzled with all that readings. I need you to bring back my head out of the water.

Thanks to you all!

Revalue

Based on the answers' upvotes, I have accepted the ones that had received the most upvotes. Besides, You all have good comments and answers and have enlightened me for a good decision over my future studies of both technologies. I wish to thank you all, and I am sorry not to be able to accept all of your answers as "the solution" of my question. Thanks! – Revalue

Answer 1

Take this with a grain of salt. I am not any kind of authority on ORM tools, but here it goes...

One of the biggest benefits that i see in EF is the GUI for mapping. IMO, this saves a lot of time, but is probably the reason why EF XML mappings are so verbose. They're not made to be dealt with manually, unfortunately. Whether it will change or not i don't know. What i do know is that the GUI that EF provides used to be very flaky in previous releases. And i still hear about people complaining that it isn't scaling well, especially on larger and more complex schemas where it just misses things and you end up messing with the mappings directly. My opinion is that XML maps will become less verbose as EF matures. You also have the fluent mapping support in EF, which is also helpful. Finally, another big thing is the ability to change code templates that EF generates, that is if you favor database-driven design instead of design-first approach.

Another benefit is that it comes from Microsoft and they have enough dough to make this a really dope framework. It has grown tremendously in the past few years. I think it'll be on the same ground with NHibernate in a little over a year. As of now, I think NHibernate is a better choice. It's more stable and mature. Relative easy to configure and most importantly a better performer. I think if you design wisely, a move from one to another is going to be a piece of cake.

EF is just an abstraction. I believe there are providers for Oracle, so i don't see why there couldn't be more added as it grows.

Porcupine

Thanks! I didn't even know that there was a GUI to design everything. I thought you had to go for the from-ground approach, just like NHibernate. This plausibly explains the verbosity of the XML-mapping files. I neither knew that it allowed database-driven, which is still today a common approach. Do you know whether it allows reverse engineering for existing systems rewritten for .NET, but where we want to keep the existing database intact? – Revalue

NHibernate has GUI/Visual Designers. – Expressly

EF4 allows for design-first approach. It allows you to plug your own domain model and map it to your data structure using XML maps or a fluent code-based approach similar to Fluent Nhibernate. Another option would be to utilize existing structure and create a domain model based on it. Which is the database-driven approach. EF4 allows you to tune the templates that it uses for domain generation, which can successfully eliminate some of the bloat that EF spits out. – Porcupine

The only way your existing tables would need to change is if you decide to start versioning your data to let EF handle concurrent operations. I mean, it is one of the options for handling that. You can do so in a programmatic way too without any DB changes. Otherwise, you can reuse your existing structure. – Porcupine

@Micheal Maddox: What are these GUI/Visual Designers for NHibernate? I don't know any. – Revalue

Michale may actually be right. I think Sculpture has a mold for NHibernate. Never used it, but it looks like a cool solution. – Porcupine

Answer 2

I know almost nothing about EF, but a quick skim of the links provided leads me to believe that EF has no equivilent to Fluent NHibernate's Automapping functionality.

Edit: Some of the commenters pointed me to links indicating there is some automapping in EF, but it's not really clear if it's as powerful as FNH (for example, being able to automap collections of other objects).

Personally, I love being able to design POCOs in an OO manner, and letting the tool handle all the busy work of mapping to a relational database.

FNH still has the most powerful automapping capability, as far as I know.

Go to Fluent NHibernate Automapping for more info.

Kilowatt

Thanks for your answer! As such, I am to discover the power offerred by Fluent NHibernate, so I haven't yet explored the Automapping feature. I read a few lines about it, but I need to make FNH work at first so that I can understand what Automapping does for the user. That's a good point! You make me think of exploring FNH at a deeper level. Perhaps is it worth to become some kind of expert with such technology. Thanks! – Revalue

Actually, EF offers a configuration builder utility that is very similar to Fluent NHibernate. Here is an article talking about it: blogs.msdn.com/adonet/pages/… – Porcupine

@user68137: Thanks! for this link. I won't miss the opportunity to visit this link. – Revalue

@user68137: I looked at the link - very interesting. One thing I'm not clear on - are the EF Configuration classes required for every business object in your model? If they are, than this is NOT the same as FNH Automapping (but it IS equivilent to what is called "Fluent Mapping" in FNH, where you need an additional Mapping class for every business object). FNH Automapping does not require additional Mapping classes - it builds the DB strictly from the business classes, cutting the programmer's work roughly in half. Please clarify, and I'll edit my answer accordingly. – Kilowatt

@Will: If the answer was useful, an upvote would be nice...:-). For me, Automapping had a fairly steep learning curve because it was my first exposure to FNH, and documentation is limited. But now that I have some experience, it's providing a tremendous productivity boost. I can create and change object models (almost) at will, and let FNH rebuild the database for me. Well worth a look, IMO. I've added a link to my answer. – Kilowatt

I don't think it's directly addressed anywhere, but the comments @ blogs.msdn.com/efdesign/archive/2009/08/03/… imply that it does automapping by default. – Introspection

@Jeff: I agree - your link does imply that they do automapping. But when I look at one of the previous posts blogs.msdn.com/efdesign/archive/2009/06/10/code-only.aspx, they show a class called MyContext which seems required to map the List<Product> member, etc. FNH would be able to automap that right out of the box. I'm guessing, but am starting to suspect that EF automaps like Subsonic does - it can do automapping of basic types, but you have to add additional code to explicitly map nested types and collections. – Kilowatt

@Tom Bushell: I don't get it, I just did upvote from zero, and it gave scored -1 =( It also says that anser is too old to be changed. =( Is there a way on SO I change fix this or report it to the moderators? – Revalue

@Will: I edited my answer based on some of the comments - maybe it will let you change your vote now. – Kilowatt

@Tom Bushell: I did upvote, at least the vote is not set to -1. Despite, it won't let me upvote again to give you the +1 vote you deserve. =( – Revalue

@Tom Bushell: I thought you tried to edited again since I did receive your message as of what you had edited your answer twice, and it removed my upvote. Please feel free to trivialy edit it and then I shall put back my upvote accordingly, then never ever touch it again for the rest of my life! ;P Thanks for your understanding. – Revalue

@Tom Bushell: I have addressed the upvoting bug on MetaSO. The bug is that the "Vote is too old to be changed, unless the post is edited", thus, I may remove the upvote by upvoting again. I thought at first that I hadn't upvote, so I did for a second time, then, my preceding upvote disappeared, and now I receive the "Vote is too old to be changed..." message. Here's the link for this bug: meta.stackexchange.com/questions/38735/… – Revalue

@Will: Did an edit, if you want to try again. If you still have problems, don't worry about it. BTW, you can tell if you have up or down voted an answer, because the corresponding arrows will turn orange. One of the (many) quirks in the SO UI :-(. – Kilowatt

@Tom Bushell: You finally have your upvote +1! Damn! If you follow up a little with the MetaSO, my report of this bug has been approved with an upvote and a few comments. Thanks for your understanding and thanks for your answer at first! =) – Revalue

Answer 3

Will EF4 tend to be less XML-verbose?

In general, I have not seen any indication that the XML will be drastically different. Microsoft is providing a Fluent like interface to EF in v4, but it's an add on / separate download.

Will EF4 be compatible with other underlying datastore than just SQL Server?

It is compatible now and it will remain compatible going forward. LinqToSql is SQL Server only, but EF has never been SQL Server only.

What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?

Honestly, there aren't many. There are little things here and there that are different, but in general NHibernate is still years ahead of EntityFramework, even in EFv4.

As a consultant, it is probably worth your time to become an expert in both NHibernate and Entity Framework. You will probably continue to see them both in the real world. Microsoft tends to have a short attention span when it comes to data access so it's not clear where Entity Framework will be a couple of years from now. Because it's from Microsoft, you can be sure that plenty of developers will use EF.

Expressly

I had header that EF was SQL Server only. Probably rumors! =) I have worked a very tiny little with the LinqToSql implementation of an ORM, and I didn't dislike. Though it was a good approach after all, you mentioned it, it was SQL Server only. I couldn't really use it because of that. As mostly a framework kind of developer, I need to be fluent with my code to react rapidly. Anyway, I guess you're right when saying that both EF and NH will co-exist in a near future. Thanks very much for your point of view! You really help enlight my thoughts about the subject. – Revalue