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!
Best Answer
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.