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

Question

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

The essence of the Framework seems to be significantly improved over the first release. Thus, I have never used EF in any project, since I think that EF is not mature enough compared to NHibernate.

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

I feel that Microsoft is only trying to get the terrain that it lost in favor of NHibernate when the second version of NHibernate was released. However, my problems are as follows (not in a specific order):

• Will EF4 be less XML verbose?
• Will EF4 be compatible with basic data stores other than SQL Server?
• What are the biggest benefits of migrating from EF4 instead of FluentNHibernate or NHibernate?

NHibernate is a great tool, I think everyone agrees. Due to its predecessor, Hibernate, we can easily find documentation and tutorials and sample applications to get to know them. This does not apply to FluentNHibernate. In particular, in accordance with the project I'm currently working on, which requires further study of NHibernate and its options (for example, FluentNHibernate) in order to document the usage rules and best practices of the NHibernate and FluentNHibernate technology. Thus, being handcuffed to VB.NET, being a C-Style developer, I cannot find some syntactic equivalences in VB.NET for the presented examples, although so far I have made my way.

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

Despite the bad comments I read about EF1, EF4 seems very promising. What do you all think about the features of NHibernate and Entity Framework? As for me, I am puzzled by all these readings. I need you to get my head back out of the water.

Thank you all!

Answer 1

Take it with salt. I am not an authority on ORM tools, but here it goes ...

One of the biggest advantages that I see in EF is the graphical interface for matching. IMO, this saves a lot of time, but is probably the reason that EF XML mappings are so verbose. Unfortunately, they cannot be processed manually. Whether this will change or not, I do not know. I really know that the graphical interface that EF provides was very unstable in previous releases. And I still hear about people complaining that it doesn't scale well, especially on larger and more complex schemes, where it just skips things, and you ended up messing up the comparisons directly. My opinion is that XML cards will become less verbose as EF matures. You also have good display support in EF, which is also useful. Finally, another important thing is the ability to modify the code templates generated by EF, that is, if you prefer a database-based design over a design-based approach.

Another advantage is that it comes from Microsoft, and they have enough test to make it really suitable. Over the past few years, it has grown significantly. I think it will be on the same land with NHibernate for a little over a year. At the moment, I think NHibernate is the best choice. He is more stable and mature. Relatively easy to configure and, most importantly, the best performer. I think that if you design wisely, the transition from one to another will be a piece of cake.

EF is just an abstraction. I believe that there are suppliers for Oracle, so I don’t understand why it can no longer be added as it grows.

Answer 2

I know almost nothing about EF, but a quick look at the links provided leads me to think that EF does not have the equivalent functionality of Fluent NHibernate Automapping .

Edit:. Some of the commentators pointed me to links indicating that EF has some automatic formatting, but it’s not entirely clear how effective it is, like FNH (for example, the ability to automate the assembly of other objects).

Personally, I like to be able to create POCOs in the OO manner and let the tool handle all the busy work against a relational database.

As far as I know, FNH still has the most powerful autopilot capabilities.

Go to Fluent NHibernate Automapping for more information.

Answer 3

Will EF4 be less XML verbose?

In general, I did not see any signs that XML would be very different. Microsoft provides a free interface for EF in V4, but it adds to / a separate download.

Will EF4 be compatible with a different underlying data warehouse than with SQL Server?

Now it is compatible, and it will remain compatible in the future. LinqToSql is only SQL Server, but EF has never been just SQL Server.

What are the biggest benefits of migrating from EF4 instead of FluentNHibernate or NHibernate?

Honestly, there are few of them. Here and there are few things that differ from each other, but overall, NHibernate is still many years ahead of EntityFramework, even in EFv4.

As a consultant, it's probably worth the time to become an expert in both NHibernate and Entity Framework. You are likely to continue to see them both in the real world. Microsoft has limited reach when it comes to data access, so it's unclear where the Entity Framework will be in a couple of years. Since this is from Microsoft, you can be sure that many developers will use EF.