7

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

Łukasz W.
  • 9,538
  • 5
  • 38
  • 63
  • Are you sure you heavly need LINQ to solve your problems? I mean that because NHib has its powerful HQL that may handle non-trivial queries. This is what I do in my projects and since I use repository pattern, any multiple object result retrieved by a repository must return an `IEnumerable`, and this is incredibly LINQ-friendly, isn't it? – Matías Fidemraizer May 31 '11 at 14:17
  • 2
    In my opinion it's inconvenient - you write some string, then debug, then correct what you made wrong, then correct again.. the whole idea with using ORM is to avoid writing SQL and have strongly typed queries.. Also it's not looking so good to have so many ways of executing queries... That makes developer unhappy, sad, frustrated... – Łukasz W. May 31 '11 at 14:22
  • (1) And LINQ queries have the same problem: you need to recompile everytime you need to correct something. HQL queries can be stored and called by name: http://ayende.com/blog/3948/nhibernate-mapping-named-queries-query-and-sql-query. – Matías Fidemraizer May 31 '11 at 14:27
  • 1
    (2) HQL isn't SQL. It's the same thing as writing LINQ: it's a high-level abstraction so you query objects instead of relational entities. – Matías Fidemraizer May 31 '11 at 14:28
  • 1
    @ŁukaszW.pl In addition to providing a linq provider NHibernate has strongly typed queries. It's called QueryOver. This was introduced in version 3. Here is a link explaining this: http://nhforge.org/blogs/nhibernate/archive/2009/12/17/queryover-in-nh-3-0.aspx – Cole W May 31 '11 at 14:28
  • (3) Having many ways of querying data is a good idea because each approach has pros and cons that may suite each one for some specific scenario and problem. – Matías Fidemraizer May 31 '11 at 14:29
  • And (4), as Cole W said, I believe you're using Nhib2Linq instead of QueryOver, but maybe I'm mistaken. – Matías Fidemraizer May 31 '11 at 14:30
  • Okay.. this discussion is going in wrong direction.. Originally I was asking if the migration will be a big trouble in this specified project... We hate nhibernate, we love linq... this ain't gonna change.. the question is if it will be better to be frustrated or to make an revolution that can end in a disaster of never-ending migration... (also we've tried queryover.. queries takes too much lines and are hard to read) – Łukasz W. May 31 '11 at 14:31
  • Here's a question for you: what database are you using.....you didn't mention that in your post. – Pharcyde Sep 13 '11 at 15:02

5 Answers5

12

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?

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • The performance improvement isn't a main goal.. it's nice-to-have.. the main issue is to make development process easier and more fun without loosing too much ;) The idea of comparing them in sample app is nice, and I will probably try it.. – Łukasz W. May 31 '11 at 14:39
  • Pardon but what kind of mechanisms NH have, that's not present in EF.. I'm just curious, because you are saying that the performance of EF is poor, but so far I've read that its on the same level as NH... Also EF4 is giving me some very nice SQL as a result, they really done they job good with a new version.. – Łukasz W. May 31 '11 at 14:46
  • I have nothing to say. You made your decision. How skilled is your team with NHibernate? – Ladislav Mrnka May 31 '11 at 14:52
  • Noto so much if you mean advanced mechanisms of this platform.. Also.. It was just I question.. I am realy curious about what NH can give me over EF.. I don't like the querying in NH but there can be a reasons why i shoud stay with it.. – Łukasz W. May 31 '11 at 14:58
  • If you want to compare NH and EF check stack overflow for related questions - there is a lot of them and you don't have to be afraid if they are not about EFv4.1 because it has same functionality as EFv4 + code first. I recommend you: Let your best NH developer do the proof of concept with EF. – Ladislav Mrnka May 31 '11 at 15:04
  • 1
    I also added two links to my answer - one pointing to some nasty queries produced by EF and second comparing how you can reduce number of round trips to the database in NH and EF. Database round trip is very costly operation. – Ladislav Mrnka May 31 '11 at 15:06
6

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!

Louis Rhys
  • 34,517
  • 56
  • 153
  • 221
Rippo
  • 22,117
  • 14
  • 78
  • 117
2

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.

Sam Sung
  • 31
  • 2
1

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.

Cole W
  • 15,123
  • 6
  • 51
  • 85
  • My mind is made up in case what I like the most.. but still I'm worrying about the time the migration could take... – Łukasz W. May 31 '11 at 14:43
0

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.

Calvin
  • 1,153
  • 2
  • 14
  • 25