I'd say, designing entities via a Designer...a lot of people still don't use NH only for a simple fact: They need a visual designer to help them create their model. Thanks to Fluent NH things are easier for regular developers (than xml mappings) but still it is no match for a desinger.

From my tweet:

"#EF can make you say "I want to use an #ORM technology, and its from MS", to your managers, #NHibernate cant. I hate it :("

• from an employer of a non-open source department of a software company.

I agree with Hadi, if nHibernate had a visual designer to manage the xml mappings that would make it unstoppable vrs EF

@Hadi, @Ori

I am tired of posting this to mailing group and etc. but NHibernate have its designer for years. It is called ActiveWriter ( http://altinoren.com/activewriter/). But after FluentNH its developer Gökhan Altınören also admitted, its better to use FNH and left its development.

So I dont think designer is a really a big advantage over NH.

@ Hadi Eskandari

Though I think, if one needs a designer and refuses to act w/out it, he is a code monkey, not a developer actually

Visual NHibernate might be just the visual designer you are looking for. It can start from an existing database, or an existing NHibernate Visual Studio project (using xml mappings) or from a blank project. It allows you to visualize and edit your projects without stomping on your existing custom code ie: if you use it with an existing project it will insert/update property definitions in your class files without touching the rest of your calss' code. It's currently in beta, and we are looking for lots of feedback as to how we can make it better for you. http://www.slyce.com

@Berke,

I've actually seen and used ActiveWriter...I really think it is not maintained and it has lots of problems (at least when I used to work with it). I think community needs a well established robust designer, maintained by NH developers.

We just build our own designer with 'DSL Tools'. It does exactly what we want it to do. We do not have to abide by the constraints of the designer of EF, or anything else.

@Hadi,

It was great and hyped when I was mentally attached to it (hence actively developing it). It was better than L2SQL designer in any way. There are too many things in NH domain not supported by ActiveWriter, but it's not that buggy IMO. Documentation is poor, though, as in most of the OSS projects.

ActiveWriter would be a great designer if using a designer is the most logical thing when dealing with O/RM mappings. It was a one-man project, only recevied some patches from helpful folks. Core NH developers will not maintain it since Fluent NH is much better and easier to deal with :)

One can continue developing it (Apache v2, sits in the Castle Contrib SVN) and bury EF in the designer front, it's not that hard. But it's not the logical thing to do, since we have FNH.

EF 4.0 has a better Linq provider than the current NHibernate implementation. This is something being actively worked on and the NH 3.0 will fix this gap.

Can you explain this statement? I.e. what I see now (I track Steve's posts) is very slow progress.

One thing that caused me problems when I first started out with NH, was the issue of duplicate entities when loading a collection of entities and eagerly loading child collections. I now know that you need to use the DistinctEntityRootTransformer, or use ISet / ICollection instead of IList, but this 'just works' with EF. I can imagine that certain developers may just give up and think NH is rubbish.

Apart from that very small thing which is solved by a quick google, NH is streets ahead of EF.

EF has a developer-experience (designer, ...) integrated with Visual Studio. That is something we can't overlook.

You can write "your own", you can buy others, but... having that tool integrated directly in VS, is a feature that makes EF a "different beast:" with NH.

And another, more subtle: EF HAS a conceptual model, vs storage model, plus mapping. NH is more "mapping-oriented".

The problem with EF: so intrusive in generated code, code close to inspection... I hope code generation is improved with the use of custom .TT.

@ajlopez

@Hadi/others: LLBLGen Pro v3 will have nhibernate 2.x and EF 1/4 (and linq to sql) support early next year, (of course with model first, various code generation options (extensible) DDL SQL generation / update, update project from DB, multiple db's per entity model, mapping validations etc..

So the 1st class designer is coming (you can even import an EF project for example and switch to NH in a few seconds ;)). It's not aimed at code-oriented people, who think FNH is the solution to their problems, as they just want to do things in a text-editor whatever they have to do. If you have many entities and want to refactor your model, you'll quickly lose overview of what's going on. Let alone the target DB migration to the new model state (with Update DDL SQL generation) which isn't there in FNH. This is important for projects which are in maintenance, which is the majority of the work done by developers anyway.

br />

What EF has over NH is being on every windows PC on the planet and in every .net developer's toolbox without effort. (it also has this over any other O/R mapper). This makes it very tough to compete with EF on the framework level. The biggest problem for 3rd party o/r mappers is that the average developer doesn't care about the downsides of EF as they'll work around it (likely they've put up with datasets' downsides for years and they just work till it's 5pm so they can go home) or just sigh and take it. I mean, every project bigger than 30-40 entities is already a problem with EF due to the canvas of the editor and the cluttered designer experience (fiddling with properties in the property grid, one of the worst editors ever) but still droves of people use it, and if they don't they give up and go back to datasets.

3rd party O/R mappers aren't in the same position as 3rd party grid controls: there's no sane developer using the vanilla datagridview in serious applications, yet, only a niche group of developers use 3rd party o/r mappers. I doubt that that will ever change.

@alex: i also read steve's posts, why do you think that are so slow?

blogs.imeta.co.uk/.../823.aspx

anyhow nobody told that nh. 3.0 will be released at 1/1/2010, when it will be finished and well tested will be released, i don't see any contradiction in the ayende's phrase

I really dont want to maintain the DB, the XML and my entity classes. The Linq2SQL or Entity Framework solution is quite perfect for me. I edit the database and just regenerate my whole data context.

We'll good documentation, IDE, tooling and LINQ support are pretty compelling reasons on their own.

Although I believe the best reason for its current and continued market share is that it is now the most recommended and supported Data Access technology suggested by Microsoft.

Because of this it will always be a first-class citizen in all other complimentary MS technologies, i.e. Dynamic Data websites, Data and RIA Services, etc.

Recently I've attempted championing the use of the NHibernate stack to replace our custom rolled O/RM at work. Even though our tools leave a lot to be desired and the continuous maintenance of these is eating in our budget and distracting heavily from core business functionality, NHibernate isn't being received well.

The problem as I see it is lack of understanding and willingness to invest time for learning an OSS. Comments such as "when I last looked at NHibernate it couldn't do what we need, though I can't remember what exactly that was" show this unreasoned animosity towards NHibernate as well as many other OSS work.

Even though the same people who abandon NHibernate without knowing it or having tried it have just as little or no experience using EF 1 thru 4, it is a Microsoft framework component and as such a viable alternative. This is a common problem shared with many other OSS vs. MS .NET framework components.

From a technical point of view, NHibernate isn't playing catch up to EF 4.0. On the contrary! But from a marketing point of view, NHibernate isn't even on the radar of competing against EF.

Doing a designer for NHibernate that is developed by the core NH staff would be a rather wasteful allocation of resources. Let's face it, designers aren't that easy to build and maintain (writing VS extensions "IS A BIG" hassle). The real question is "does NHibernate intend to cater those developers who require a designer?" I think not. NHibernate isn't your 'quick 'n dirty' mom & pop O/RM to build store application demos and one-off blogs. Those who do may feel free to use a designer if they feel inclined to do so.

If anything, I'll return to my statement that NHibernate is not marketed and commercialized well enough. By that I mean there's no JBoss behind it, there are no paid, full-time staff working on it, there's no (or only little known) clear commercial support and of course, there's no regular, targeted propaganda.

Sure, there are some very dedicated and most talented developers working on NHibernate, but other commitments pay their bills.

Of course, if you look hard you can get commercial support and I am sure it would be the best that's available, but Oren and Fabio can't possibly support a worldwide, corporate user base.

Okay, NHibernate is under the Hibernate umbrella which in turn is under the JBoss umbrella and so on, but what do we MS-ers care about JBoss? Where's our foundation promoting and supporting relevant OSS (still to see where Codeplex Foundation will head to).

Granted, we can find occasional one-liners such as "we are using NHibernate in our critical enterprise application for years now" but where are those stories? Where are those detailed, nitty-gritty articles telling us and showing us how and where NHibernate is used and excels in what it does? Where's NHibernate's Steven Balmer shouting "NHibernate, NHibernate, NHibernate!"

Some may say those are evil distractors, but to me, that's what it takes to convince bosses and talented yet narrow-sighted developers and that's where EF rises and shines high above NH. It's often irrelevant to highlight the technical benefits of X over Y when others already believe in either one.

One thing I can't see me do in a designer is domain behavior, something that doesn't apply in all situations of course you might be doing CRUD while using NHibernate or EF or ... And when doing CRUD I can surely see the benefits from using a designer, but when I need to model a domain with behavior then a designer is not what I want. there I really want to push the design using TDD or BDD and I have no clue how you would drive this from a designer? One thing that gets useful then is the ability to view the domain model to get an overview.

I do think that NHibernate needs some very straight forward guides on how to setup a project, perhaps even an ready to go example project. The same applies when using Fluent NHibernate.

-Mark

Getting nhibernate to run in a medium trust environment is a real pita. I spent a few hours yesterday doing just that. Are there any plans to test future releases with medium trust restrictions? There have been some recent changes to the castle dynamic proxy that allow it to run in medium trust post 2.0 sp1. The only other issue seems to be refection optimization.

Just funny that the entire premise of the 'ORM' in my opinion is the ability to build POCO domain objects.

And 90% of these posts complain that NH doesn't have a generated closed code system where you can't add busines logic to domain objects :)

From early glimpse of EF v4, you can do 'POCO', but there is no designer for that - right? It's all convention based correct ?

In other words, through a 'visual designer' you get the equivalent of glorified datasets, not rich domain objects.

I'd add though to the commercial projects here... the EF/L2SQL designer is free.

So I guess if your just looking for some RAD 'dataset' like tool, then EF is a great fit for you. If you want domain objects, POCO objects, etc... the maybe not.

Ayende - there are 2 other areas I could think of, maybe it's in NH now:

1. Support for DomainService in RIA.NET. Currently there is a EF/L2S only I think ?

2. Support for ADO.NET Data services (same as #1)

Just to throw this in... EF/L2S is really missing some core features you'd get from a legacy database, like the ability to have hilo, etc...

As far as Fluent NHibernate - it's missing good support for SQL integration still, correct ?

I just was at a company that started to consider EF, but then was quickly unable to do the core items needed, we shifted to NH and were able to address every issue (ie. we needed an append only model, we needed certain SQL/function support - with EF it was all or nothing, we needed the interceptor support - NH has a rich event model for tapping into the process)

These are all 'edge cases' - but it's the edge cases imo that separate the men from the boys. Anyone can do a 1 to many query on a new database table where you can control the structure and normalization aspects. But to map to a complex legacy database system... that is where having the flexibility of NHibernate is .... priceless :)

@ Mark Nijhof: depends on what you consider a 'domain object': if it's an entity or if it's a class which for example encapsulates 1 or more entities (e.g. aggregate root + its value types, like Order + its orderlines).

Designers are mainly there to maintain mappings and make sure 'the other side' is kept in sync (be it entities which are reverse engineered from a relational model, or tables which are engineered from mappings). This isn't always trivial and every manual labor involved to make mappings work again (and migrate target tables) is error prone. Designers can help there, as long as you use them for the parts of the whole chain which you can better outsource to a tool.

After all both classes and tables are projection results of abstract entity definitions, otherwise you can't create a bidirectional mapping between each other.

@Steve: "In other words, through a 'visual designer' you get the equivalent of glorified datasets, not rich domain objects."

I really think you are still stuck in the last century. Technology has moved on, you know. code generation isn't as dumb as it was years ago.

It has 150 developers, prime time commtiment from company having endless money to pour in on demand, army of doc writters, evangelists, book writters etc...

It also has prime time integration with other data technologies from MS

To me personally seeing the advance being made from EF3.5 to EF4 (POCO, T4, CodeFirst etc) + all the things above is a clear sign that NHibernate doesn't have a chance aginst EF on long term because sooner or later EFx would match the NHIbernate feture stack and from that moment NH would be past

Sad but true...

One of the guys here nailed it for me:

EF is from Microsoft, NH is not.

At the end of the day, it's easier for a Manager to support using a Microsoft-supported framework versus an open source one when an option exists.

Is it right? No. But, that's the way it is.

At first I was taken back by the lack of a visual designer. I have never been a fan of XML and probably never will, it just add too much noise. I tried various designer for NHibernate including ActiveWriter with the intention to extend it.

Half way through the project I end up nuking one of my machine before backing it up. I swear I did :) but apparently not. This turn out to be a bless in this disguise. Since my whole experience with a visual designer wasn't all that positive, they all feel too clunky, they all took too many click say to add a simple property.

So I pulled down a copy of FluentNHibernate do a quick spike to learn about it various capabilities. After about half an hour I wonder why did I even bother to try a visual designer in the first place. This is especially true for a Greenfield project. If you follow a certain convention in your model most of your mapping is automatic with FNH. It's fast, it's easy to use, it's great to refactor. All the same time it also support any custom mapping that you might need. Needless to say I am a big fan :)

Steve,

I don't know about Data services but NHibernate work perfectly fine with WCF RIA services. There is no "built in" provider but it's a matter of 10 minutes to write one (just inherit from domainservice and add the few lines for playing with ISession.

Notice that it's not (just) NHibernate magic but the fact that RIA services is actually data provider agnostic (one of the webcast from pdc about RIA Services use NHibernate).

I think one of the big things that everyone is missing about EF vs NH is the fact that with EF there is more down stream integration that can happen, and more that will happen as time goes on. Being that you have a model that can be re-used in reports, BI, Analysis, RESTFul services with WCF Data Services and so on. You don't get any of that with NH, you just get an ORM.

The EF team hasn't shown their whole hand yet as to where EF is going, and they'll continue to improve things. But, to me the big thing about EF is the dog fooding that is going to occur in other product teams.

-Keith

@Gareth Hayter - EF can start from a blank Oracle DB. Visual NHibernate can't.

From my experience the only way to ORM is by hand- which requires competency. I don't want a designer to get it 80% of the way there requiring me to do the rest of the 20% and then continue to maintain changes by hand, this is backwards.

There are plenty of free code generation tools to generate mapping files from database to get you 80% if you already have a database. ORM requires competency EF or Designer or not.

@Steve you said: "Just funny that the entire premise of the 'ORM' in my opinion is the ability to build POCO domain objects."

I wholly disagree with this. ORM is about abstracting the plumbing needed to get data from a data store into an object graph. Heck, it's in the name.. Mapping Relational Data to Object or ORM for short.

There is nothing in the name that says the premise is about POCO. Persistence ignorance isn't required to do ORM. Certainly it is desirable for many, although have you yet to switch from one ORM engine to another retaining all your model classes. Has ANYONE ever done this.

There are several ORMs that do a very good job and don't have POCO model layer. LLBLGEN Pro, Deklarit and a few others I'm sure I am forgetting.

BOb

Reading the comments, it appears as though the folks championing the EF side are very data-driven - db first and whatnot, which isn't surprising, that's generally the approach that Microsoft tends to push, and works well if you want to work in and are more comfortable in the end to end MS stack.

I used LLBLGen before I switched to NH, and it was a great tool. It also helps that Frans does such fantastic support, too. I haven't had the opportunity to use the newer versions (I think the last version I used was 2.5), so take this next bit with that in mind.

I fell in love with NH because it allowed me to develop software that wasn't necessarily tied to the relational or table driven model, I could finally model real world behavior in a completely OO way. It felt more natural for me. I can then shuttle the actual persistence off to db if I need to. Persistance ignorance isn't about switching databases, it's about potentially switching the entire TYPE of datastore that you use, which can happen as you scale your application - ie moving from dev to prod, to trying to scale prod and bringing in tools like second level caches and document databases.

I've also fallen in love with the additional toolsets that plug into NH, like Validator and the excellent Search plugin. Being able to add full-on Lucene searching (in about a day and a half) to my data model is a dream.

With the move to a CQRS architecture that I'm making right now, I'm going to stick with NH because I can mock up the persistence DTOs that feed into the Query side of the equation in development, then evolve them to persistent objects with Fluent NH in minutes. Adopting this kind of architecture will be easy because I really don't have to change any of my models at all or think about which persistence mechanism we're going to go with.

I haven't used EF at all, so it may just be that I haven't explore all of the options out there, but NH suits my needs so perfectly that I haven't really felt the need either.

@Karloff

but...but, my one-off blog IS written with NH and FNH. I loved it. No pixel-pushing, just pure resharper-fuelled text editor power.

The only bit of SQL I wrote is this line here:

model.Override <content(a => a.Map(c => c.Body).CustomSqlType("nvarchar(MAX)"));

Admittedly, it's only a fragment.

Anyone can load up VS and start using EF. That's a much bigger advantage than the ALT.Net crew understands.

Why are there more IronPython users than Boo users? It's certainly not because IronPython is better language and not even that it has better .NET integration. It's all about the tooling.

@Jason, there's a simple answer for that. Change where you work. :)

@Keith, surely you're saying that in jest, yes? :) The one-grand-model-to-rule-them-all quickly falls apart in anything but simplest forms-over-data/CRUD-all-the-way stuff.

It's all about context and at the very least you've got two contexts: writing & reading. And remember, every read is really a report. In the end you're going to have several contexts, each bounded and optimized for the thing they are doing, and each with it's own model.

-steve

I'm not saying one model to rule them all, what I am saying is there are other things that EF models can and will be used for. NH doesn't offer any of that. This is a discussion on what does EF do that NH doesn't do, so just pointing out that downstream things are going to leverage that model, whether you have one, or 2, or 30. Doesn't matter.

Just remember that there are other tools out there that complement NHibernate (such as Lucene).

I would argue that NHibernate's "model" is more flexible and ready for extensibility than an EF model--given that the NHibernate model is usually a set of POCO classes.

However, let's not descend into a comparison that plays out much like a TFS vs GIT thread (where GIT is only one tool in the box).. :-)

Evan

EF will surpass NHibernate feature-wise. When MS focuses and devotes resources to something to the level that they are doing with EF, it is just a matter of time. However, this isn't to say that EF will end up being a necessarily "better" tool than NHibernate. NHibernate has the advantage of being focused on a simple concept, ORM. With every product I can think of that has come out of Microsoft beyond very core level libraries, bloat always happens as they try to target sub-average developers and managers with all kinds of bells and whistles that just get in the way of addressing the core problem space.

For example, I wouldn't be surprised if the Entity Framework would eventually have first-class GUI support in future versions of WPF/VS where you can do something like drag an entity onto a window in the designer and automagically hook up GUI fields to the entity fields. Of course this ability would require all kinds of cr*p to be added (generated) to the entity classes and would end up being useless for anything but a tech demo to impress managers with how much programmer time they can save (of course it is only saved until someone needs to change the basic behavior).

So, I think bloat will kill EF in the minds of serious developers over time, but, yes...this is actually a sales advantage for MS that NHibernate cannot compete with.

Can NHibernate retrieve hierarchies (orders+orderlines+other 1 to many) with a single SQL statement?

@Evan

You realize that EF supports POCO as well?

@Keith,

Not nearly to the same extent as NH. There are a couple levels of PI/POCO that are important. Being able to construct and exercise the entities independently of the database is a big first step. Being able to do what the EF guys call "Code First" or "Model First" is a nice second step, but AFAIK ,EF makes too many harmful restrictions on how you can shape your entities. From what I can tell, EF 4 is still unusable if you want/need to build a rich Domain Model.

This is a massive anti-pattern that all the EF 4 samples I see do:

public class PersistedEntity

{

// No way in hell should this be a public property

public IList <item Items {get;set;}

}

@RichB, Visual NHibernate is still in beta. Oracle and MySQL support are on their way.

I'll still never use NHibernate unless I don't get given the choice. Too much time is wasted on maintaining XML files or Classes and attributes on a project that doesn't have a concrete domain model to begin with.

Being able to use EF or LightSpeed with its VS tools makes things much more productive. And for most project you don't lose anything in regards to functionality or features when using either over NH.

Just for those looking for a Visual designer for NHibernate integrated with visual studio:

http://www.slyce.com/

Felice Pollano is studying a way to realize use the EF designer and change its T4 template to create "others" artefacts (guess which are).

Note: not start from an existing schema is not a limitation but an advantage; You should start from your domain and then, only then, you can take the decision about its persistent representation.

Btw, IMO, there isn't a "NH vs EF"... it is only a "NH OR EF"

@Fabio, Visual NHibernate is not a VS plugin...yet. If enough people ask for it then we'll consider making it a VS plugin.

Visual NHibernate allows you to start from existing code: point at your existing VS project file and it will reverse-engineer the XML mapping files and parse your C# code to create the model.

Of course, you can also start from an existing database, but most of our users use it to maintain existing projects.

We have added some support for NH Validator and will complete this support soon. After that maybe Lucene support, or whatever our users tell us they want.

It is trivial in EF4 to be able to query entities that are cached by the identity map through ObjectStateManager. Does anyone know if it is possible in NHibernate? I am looking for a way to do an extension method, say QueryLocal <tentity(), that would return an IEnumerable <tentity collection cached by the identity map.

That and a real LINQ provider are the 2 things that I am missing in NHibernate. Otherwise, NHibernate is much more powerful.

Also, can NHibernate do a DISTINCT db query without using HQL/SQL? DistinctEntityRootTransformer filters duplicates in memory.

I'm working on a TT templating solution as @Fabio said in previous comment. However the template is not ( yet ) integrated in Visual Studio, just because at the moment the VS integration of TT is a little poor:the pattern is one tt, one generated file, any other approach are some triks and I don't trust those solutions. So the current hbm2net solutions is still a console application, that I use as a pre-build step in VS. This works just fine for me, and the other internal tool SchemaExport close the job. So the only thing I maintain are the hbm. If you don't like the generated code, just change the TT file. IMHO, a graphical designer fails when it just put boxes around the xml tags, in such a case it does not add any value in producing code, writing hbm ( with intellisense enabled ) is fast enougth, and is a "zero impedence" approach to the extremely detailed mapping configuration of NH.

Perhaps nHibernate doesn't support regular 'Drag and Drop' developers :). I am sure if you take a count, those kind of developers will outnumber ALT.NETters by a magnitude.

Another Reason : nHibernate though being such potent product, is sparse on stuffs people use for learning like Books, Videos etc.

After so many years, still nHibernate just has 1 book : nHibernate in Action

@Steve Gentile: Almost everything you have said or assumed about EF4 is wrong. You can generate POCO classes from the designer, you can make full domain objects via the designer... etc.

@Nikola: 150 developers? Are you kidding me? The EF dev team is about 15 people.

[)amien

What most people who want to setup mappings in code files seem to forget is that once your application is in production, you really want to have migration features where you migrate your model to a new state and you want to have mappings and target tables to migrate with that as well. Unless you use a 1:1 mapping paradigm (still maintenance unfriendly), you're in for a lot of manual checking and labor whether your new code is indeed working. For example, when making an entity X a subtype of entity Y, when you change a 1:n to 1:1, these have effects on the DB as well, which has to be migrated, not whiped, as it's already in production.

When you're doing new development on a new system, you have the luxury to drop the schema and recreate a new one. Once you're in maintenance mode (and the vast majority of developers do maintenance work, and this number only grows in the future), you can't simply drop a schema, you have to migrate it.

If all you have to do is rightclick an entity, select 'make subtype of' and push a button to emit new update DDL SQL and mapping files (and if you want, classes), how are you going to tell your client that you have to spend way more time on your text files to make sure everything is migrated properly, and make these changes by hand? That's why there are tools.

It's key that these tools offer you the flexibility to emit the stuff you need in the form you need it , e.g. only mapping files, or scaffolded classes, etc. Code generators in the past often were 'there's just one type of output' kind of tools but that time is over. When code generators are put to work as typing machines (which they are) there's nothing wrong with using them, or you must be too stubborn to believe a machine can create better code than you can.

I too think that EF in the end will have all features NH has and much more. That's simply inevitable and every O/R mapper developer outside MS knows this for a long time already. There's one aspect which will make it or break it though: tooling. No tooling, no users. Sure some will put up with the arcane tools MS ships or with xml files all over the place, but many won't and rightfully so. We developers aren't payed to mess with infrastructure configuration files, we're payed to solve problems.

@Jeremy

I think you should blog about that in more detail.

Damien above says : "Almost everything you have said or assumed about EF4 is wrong. You can generate POCO classes from the designer, you can make full domain objects via the designer... etc."

If everything I said is wrong, why is EF v4 touting that it's going to provide true POCO support in version 4 ?

Reference:

blogs.msdn.com/.../...k-part-1-the-experience.aspx

" that support for POCO entities is one of the new capabilities we have added to Entity Framework 4.0. This week, I’d like to go into the details of POCO support in Entity Framework 4.0."

From EF dev blog. Again, if POCO was in version 1.0 why would this be a new feature in version 4.0 ???

I fired up VS and created a EF 1.0 project, I don't see any POCO objects.

I tend to rely a lot on property change notifications in my domain objects and do not like NH replacing the internals of my domain objects (OOTB behaviour, although I realise that this could be changed). I looked into the use of NH seriously two years ago and chose to not adopt it for this reason.

It's interesting to me that this is not an issue for others. I review my ORM regularly and may use EF in the future, but because of the above would tend not to favour NH. Lack of LINQ support and having to work with XML configuration were also factors in my choice two years ago, although not so relevant now (patchy VistaDB support too).

I don't wish for that to sound critical as I have a lot of respect for NH and its community. Also, I agree strongly with @PilotBob that POCO should not be considered an important goal. The reason I use an ORM is to allow me to focus on my domain objects and not to have to mess around with data access code. IMO, that's the primary goal of an ORM.

I won't be saying that EF is better than NH. But here are couple of reasons that I think people will move to EF than NH.

1) EF is from Microsoft! This is a big thing and people trust Microsoft (Don't ask me why). We have seen this issue when adopting several other tools including TFS vs Git debate.

2) EF might have better support since it is from Microsoft and most of the people will be using it. I have experienced that although NH has support but it is not as responsive as the MS counterpart. The main reason is that NH is open source project while MS is a paid product.

3) NH has a steep learning curve. If you ask a new developer to insert a record in the database then it will take him 5 min using EF and about 30 min using NH.

I think NH is a superb product and it cannot be matched with any OR mapper but when buying the product most people will go towards the branded product rather than OSS.

I still don't get, where people take this "oh mighty NHibernate, steep is your learning curve". Sure, if you have already read gazillion "how to count to three in EF" articles and then you try it, learning curve to NHibernate might seem steeper. But if I look at the both API-s and entry level how-to docs, they look exactly the same.

I can't believe people still trot out the visual designer argument. It is such a bad practice to build up your architecture using a designer (UI is another story, but even UI developers switch between the designer to the markup frequently). I just feel anyone who needs a designer to work with a database is not really learning how to develop software.

You can design an entire database schema just using nHibernate, fluent nhibernate and SchemaExport (which is part of nHibernate). You simply defining your entities in code, auto generate the mappings with fluent nhibernate and create and run the DDL against the database with SchemaExport.

This approach is a whole level faster and easier than working with a designer it is just silly.

I 100% agree with Nathan.

IronPython and EF wins simply because they are MS products and intregrated with the IDE.

Also, regarding EF4:

EF POCO supports dirty tracking through both snapshots AND by proxy interception.

Proxy intercepted dirty tracking gives MUCH better performance on commit.

You can argue all you want that you shouldn't have many objects loaded at once... there are cases where you need to handle somewhat large graphs and in those cases the intercepted dirty tracking wins.

EF POCO does not expose associations as ghosts proxies of base type.

It exposes objects of the correct proxied subtype.

So it does not come with the "leaky this" problem.

Friction at code level costs more than a "join" at DB level.

I'm uncertain of this one:

EF handles eager load of multiple child list associations very nicely.

It generates a select statement for each child path and then "union all" them into a single result set.

Avoiding cartesian products.

Not sure how NH handles that.

Again, EF comes with a designer ;-)

And in response to any code monkey statements.

You can do model first and then generate the DB from it.

You can generate partial POCO classes.

(I've got templates for it, and MS will release their own for Beta2 soon)

You can refactor entity properties into value objects.

Regarding the decent LINQ support, EF has it , NH don't.

"we will in the future" doesn't count.

And according to your arch enemy Ormbattle, EF is faster than NH too.

Also, it's not about who has the most features.

It's about who has the best user experience and enough features.

Has anybody considered a possibility to cooperate with Microsoft and come into mutual agreement to distribute both EF and NH as part of .Net framework?

I know at the moment this idea is more an idee-fix. However, in the long run i think such model would really benefit everybody.

I don't care what tool i use as long as the tool does the job right. So why not distribute these two tools (and MVC, MonoRail, etc etc) together?

IMHO, MS does not get direct revenue from developers using EF and MVC / ASP.Net. What they really get is people using their platform, which i must admit is great. Such cooperation would attract even more developers to .Net platform, and extend MS product target audience.

FWIW, One of my big New Year's resolutions is to become fully conversant with NHibernate and Fluent NHibernate. I like EF, but I don't have the time to wait around. With Fluent, a Visual Designer becomes much less of a need.

@Steve: We are talking about EFv4 here and I said you can use the designer to create POCO classes - you can.

Why on earth are you taking that to mean anything about EFv1?

[)amien