Migration from NHibernate to Entity Framework 4.1?

Question

I am aware that this question may be a little bit dangerous to ask, but I really need some opinion with this.

We've got our system, it's an website (will be popular web portal, we use MVC3) and before I was here rest of my co-woorkers chose NHibernate as their OR Mapper solution, and they started to write criteria queries and such..

Right now the team is closer to Linq approach, so we tried to wrote queries in built-in Linq provider.. The thing is.. it's horribly adapted - literally you cannot write non-trivial query and do not get Not supported exception ...

We decided that it's the last possible moment, to change our OR Mapper to something more Linq-based and we since the EF4.1 got ultrafriendly Code First option, we are decided that this is what we need.

The problem that I need some opinions on it is worth the time to migrate from NHibernate to EF4.1... The project will last at least one year further in development, so we have a lot of work to do, and we want to do it in nice and non-frustrating way..

Some facts:

• We have about 50 entities in our project
• We have about 160 queries written in Criteria API (all covered in unit tests)
• We need to have composite, inheritance and many-many support
• The project will be twice as big as it is now
• We are not satisfied with our database performance
• We hate the way that we write queries right now!

So.. now.. is migration a good or bad idea? Will EF resolve our problems, will it make us happy or that step will be just the waste of our time?

Regards

Answer 1

Be aware that you will exchange better linq support for worse mapping functionality and sometimes much worse performance ( inheritance queries , no query or command batching , ...). Now return to the blackboard and think again. If you don't like your database performance now, it will hardly improve with EF.

I guess it is little bit late to change the technology - it will have high cost. But anyway if you really want to do it why not to make proof-of-concept where you take some really complex mapped feature with some advanced queries and try to do the same in EF code first? You can test the same just in simple console application and compare both mapping experience and queries + performance.

Performance is perhaps not an issue at the moment but it can be something you really have to optimize in the future and EF will provide you much less features for that. If you want to improve performance of EF solution you very often revert back to native SQL and stored procedures. Do you thing that it will have better experience for writing queries?

Answer 2

I have to agree with @Ladislav, EF and LINQ is nice it just works compared to NHibernate LINQ, however the SQL EF generates sometimes is pretty terrible and is not terribly performant and you will be forced to recode complex queries into views and SP's etc. Nhibernate also can fall into this trap however having many different options is a benefit as you can cherry pick the best one to suit your needs.

I suppose you are looking at balancing the following:-

1. rewrite using EF and then revisting ugly/slow generated SQL into more performant database queries
2. use NHibernate and drop LINQ for anything too complex into Criteria/QueryOver/HQL

Kinda jumping from one ORM into another can be like jumping from the frying pan into the fire. Both have their sweet spots both will burn your fingers!

Answer 3

Personally I also come across the issues with the linq provider for Nhibernate.

However, I chose to stick with NHibernate because of its "proper" SQL-generation, overall performance and extensibility.

The latter allows you to alleviate your RDBMS with a 2nd level cache of your choice, such as MemcacheD. It keeps the objects in-memory (on the MemcacheD server) fetching/committing them from/to the RDBMS only if needed. Also applies to compiled SQL-queries.

Answer 4

Well to be honest it sounds like you've already made up your mind. I'm not sure what you are really asking here. If you are interested in sticking with NHibernate you should ask specific questions on problems you are having.

In my opinion if your team is more familiar with EF then you should switch. If they aren't then I'm not sure if you will ever know if the EF will solve all of your problems unless you actually outline the specific problems you are having.

Answer 5

Did you try Fluent NHibernate? http://fluentnhibernate.org/ . You can use LINQ with it. I used it in a project and it worked very well.