Why NHibernate and not Entity Framework

Topics: Core, Customizing Orchard, General, Writing modules
Sep 24, 2012 at 1:05 PM
Edited Sep 24, 2012 at 1:47 PM

Hello,

New to Orchard, I discovered I have to learn NHibernate to understand the source code.
Why not using Entity Framework, was is a matter of maturity at the time Orchard project was started.

Is their a technical choice in Entity Framework which make it incompatible with Orchard ?
Does a move to Entity Famework would make some sense ?

Thanks for clarification and comments.

CS

Addendum: my question was also related to this post 

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

 

Coordinator
Sep 24, 2012 at 5:08 PM

This has been asked many times before so I'll be brief. When we started building Orchard, EF was not open-source, and immensely inferior, in particular with regards to the automatic schema generation and mapping features that we absolutely needed. EF got better over time but is still lacking some critical features. Moving to EF would be very difficult and above all doesn't have any clear advantages. nHibernate works today. Really, what's the point?

One thing we are considering and that would have clear advantages, is to move to a document database, probably built on nHibernate as well.

Sep 24, 2012 at 5:35 PM

nHibernate is vastly superior to EF. The EF project was started by some OS and SQL Server devs at Microsoft with grand dreams of creating "not just an ORM", but a magical, universal data platform. It turned out they had no idea of how complex a beast a proper OLTP ORM is. Nowadays EF is just an ORM, but still has lots and lots and lots of features to copy from nHibernate - second level and query cache, stable support of all popular RDBMs, performant inheritance mapping, etc.

Developer
Sep 24, 2012 at 7:23 PM

Please also note, in the vast majority of cases, you DONT need to learn NHibernate, Orchard puts a wrapper around it so you do not have to interact with it.

Nick

Sep 26, 2012 at 10:02 AM

Thanks for answers, I understand the situation.

It seems clear that for the multi DB target Nhibernate is still superior to EF.
But EF in its last version seems the best when you run last .NET and linQ versions.

But there is a clear challenge and question concerning the futur of EF: could get better, could be' abandonned'.

Changing an ORM is a time consumming solution, certainly to late for Orchard. I don't clearly see the work to be done ?

 By the way, even if we don't need to understand NH to use Orchard, moving to a more technical work can't be seriously done without understanding what is going on behind the scene.

CS

Feb 7, 2014 at 10:59 AM
Hi Bertrandleroy / All,

I agree that EF was very immature and not open source at the time Orchard was started. But it has come a long way. It is opensource and backed by Microsoft.

We are deciding on a framework to start a large business application which we will need to support for a long time. We had narrowed down on Orchard for the same. It has everything we need right now. nHibernate too works brilliantly. We had made up our mind on using Orchard Framework until I read up a little on EF 6+

Here are some links I would like to share with you guys :-

http://www.devbridge.com/articles/entity-framework-6-vs-nhibernate-4/

http://channel9.msdn.com/series/Building-Modern-Web-Apps/05

I am worried about the long term support and features for nHibernate.

Do you think at some point you guys will consider moving to EF ?

Regards,
Yashvit
Developer
Feb 7, 2014 at 11:57 AM
The only thing I find worrying about NHibernate, but this only for the medium term, the lack of async support (and the lack of plans for it). Even if NHibernate had async support for queries (since queries, as seen from the web server, are just I/O operations that should ideally be executed asynchronously) Orchard would need an enormous amount of work to make use of it. Thus, although this is something I find important and that will get more important in the future as a performance consideration it's not something to worry about right now.
Mar 11, 2014 at 12:32 PM
It could be good to have support for ef6 and async method in asp.net mvc. What needs to change? Maybe its worth the effort...
Mar 11, 2014 at 4:16 PM
What needs to change? What about everything? ;)

You can always code everything yourself and offer it to the community, but I honestly do not think such a switch is worth the effort (and risk)
Mar 12, 2014 at 2:34 PM
Ok,, lets use it as is
Mar 12, 2014 at 3:42 PM
Several months after this first post and hundred lines of orchard code written, I would say that NH is still a pain and statistically speaking generating a great part of the orchard issues (just browse issues).
In the meantime I have also been using EF on different projects and appreciated its flexibility and efficiency.
One point not mentioned in your very interesting links EF vs NH is autofac: NH has very solid (but old) autofac support, not EF, that's a problem.
Especially when speaking of Orchard which is a complex and well done autofac architecture implementation, this is a point blocking EF usage.
The other point is that NH concepts have not been restricted to an Orm layer or interface, they are each and everywhere in Orchard code, which means that any move to another thing than NH is quite impossible.
Being an old SQL server fan, I am afraid by what NH is doing with data, in orchard it uses 10% of the capabilities of such a war engine: no sps, no special types, no triggers, no fine tuning of locks, no fine tuning of transactions, no multi level transactions....everything is bring from db on each and every request...etc.
The next 1.8 version is presented as a step in the Orchard migration to a document DB model, but from what I see it still totally relies on NH, no move to restrict NH code behind an interface layer as I was expecting.
Ideally Orchard should not use SQL databases, so no SQL orm, but what ?
Mar 12, 2014 at 4:29 PM
CSADNT wrote:
Several months after this first post and hundred lines of orchard code written, I would say that NH is still a pain and statistically speaking generating a great part of the orchard issues (just browse issues).
In the meantime I have also been using EF on different projects and appreciated its flexibility and efficiency.
One point not mentioned in your very interesting links EF vs NH is autofac: NH has very solid (but old) autofac support, not EF, that's a problem.
Especially when speaking of Orchard which is a complex and well done autofac architecture implementation, this is a point blocking EF usage.
The other point is that NH concepts have not been restricted to an Orm layer or interface, they are each and everywhere in Orchard code, which means that any move to another thing than NH is quite impossible.
Being an old SQL server fan, I am afraid by what NH is doing with data, in orchard it uses 10% of the capabilities of such a war engine: no sps, no special types, no triggers, no fine tuning of locks, no fine tuning of transactions, no multi level transactions....everything is bring from db on each and every request...etc.
The next 1.8 version is presented as a step in the Orchard migration to a document DB model, but from what I see it still totally relies on NH, no move to restrict NH code behind an interface layer as I was expecting.
Ideally Orchard should not use SQL databases, so no SQL orm, but what ?
You shouldn't be using a CMS if you want to fully exploit anything imho.

You should make something from scratch then and design everything from the ground up.

IMHO: Using a CMS, you win some, you lose some.
Mar 12, 2014 at 4:42 PM
@AimOrchard: I always appreciate your comments, especially when you answer the asked questions, so let's be positive and don't make a personnal question of everything :)
But you are right, I am also doing things from scratch, it helps visibility.
IMHO :)
Mar 12, 2014 at 4:49 PM
I wish I could do things from scratch, but that ain't part of my job ;)

But, I do get to do core hacks and do rather low level improvements to our Orchard core, so that compensates a bit :)

Out of all your remarks, the biggest blocker (at least for a non major update for Orchard) would be (for me): backwards compatilbility.

Ow and no worries, I didn't take anything personal ;) * puts down the shotgun *
Mar 12, 2014 at 5:06 PM
Ok fine.
I know that we could continue this in French and I have been on one of the sites you created, and keep reading your comments and suggestions.
Doing from scratch is a luxe you reach when you have been counting many many years spent on keyboards or/and when you are in position of forgetting the stress introduced by society :)

You are right compatibility is actually impossible as the database is modelled according NH concepts, impossible to reuse with something else, that is also a consequence of my previous remark, NH is everywhere in Orchard.
Anyway 1.8 is already introducing some level of incompatibility, moving is only one direction (up).
I think that some guies will continue a long time on 1.7.x .
Have you moved ?
Mar 12, 2014 at 5:47 PM
No, we are still on ~1.6 even.

We upgraded some specific bits (as in backported some 1.7 changes), but at the moment we don't consider the effort needed to upgrade to 1.7.* something we can sell to our client.

Neither do we not see a specific need yet to switch over: with our most recent changes, we got the performance up to a level we consider 'very good', and everything 'works' as our client expects ;)

Also, it wouldn't be bad if Orchard picked up the pace regarding releasing versions that contains hotfixes.

Usually the best you get now is "yeah, its a critical bug that is fixed on 1.x".

If they KNOW a critical bug was fixed, they should make work of bringing out a release asap, instead of stating "yeah, just use the trunk", because that is the signal I'm getting from them.

Like this, the current release flow is seriously flawed.

Another reason I'm sometimes strongly protesting about 'big new things' being added to Orchard: what about cleaning up the stuff you already have?
Developer
Mar 12, 2014 at 6:12 PM
This is getting a bit off-topic and I'd suggest to take it to a new thread.

@AimOrchard: as someone feeling to be part of the "they", let me express that I believe there is just one "we". You're not a customer and others are not developers of Orchard. We all are customers and developers of and for Orchard at the same time: this is open source. You can speak up, initiate a change. The weekly meetings are open, the discussion board is open. If you want to say something, you can, and please do.

The important point you're making that Orchard currently lacks a professional release management with a planned release cycle, what is indeed an issue. As it is often with open source projects - with great freedom comes great disorganisation (and Orchard is doing great on contrary to a lot of other OS projects). But you can make a real difference, as opposed to closed-source. How should we do it? Who will do it (i.e. who will pay for it)? How will we make decisions and who will make them? What should be the overall goals and product strategy? Short term, mid term, long term? If there are conflicting interests, how should we resolve? Where and how should all this be communicated?

Don't take me wrong, I'm not trying to insult or push you. You're raising awareness to something important.
Coordinator
Mar 12, 2014 at 6:12 PM
We all agree about the pain points. One solution would be to remove the abstractions around NH and show it directly so you can do QueryOver, Criteria or HQL queries directly, with extension methods to help doing queries on Content Items.

But changing the data access layer would mean deep breaking changes. In modules mostly. And the only upgrade path would be to have all modules re-implemented, and use import/export features. But even though, the gallery modules would never be ready, and having a new layer would also break the export format on a per module basis. So to be honest there would be no possible upgrade path.

This could be a 2.0 discussion to have, where the DAL would be replaced, even with a NoSql vision (we talked about YesSql, other options are open) and a new Gallery with only modules targeting 2.0 so there would be no surprise when installing modules.

Let's ship 1.8, we already have plans for 1.9, then we can talk. If you have anything in mind continue to share it, I an taking notes ;)
Mar 12, 2014 at 6:13 PM
Edited Mar 12, 2014 at 6:15 PM
@AimOrchard: Clear.
I am on 1.7.x and plan to move to 1.8 but 1.8 is permanently moving.
I compared fixes in 1.7.x and 1.x but don't understand why some have been applyed only to 1.x ?
Incitation to move to 1.8 ?
Years ago I was following YAF and it was very similar to Orchard ?
May be the community has not reached such an audience that an obsolute necessity to use processes such as the one you mention exists.
Very strange, I have also followed large Linux Open Source Projects in the past as RT or other telecom tools they seemed more pro.
Jan 26, 2015 at 7:20 AM
mark this post