NHibernate vs. Entity Framework 4.0
This is a question that I get very frequently, and I always tried to dodged the bullet, but I get it so much that I feel that I have to provide an answer. Obviously, I am (not so) slightly biased toward NHibernate, so while you read it, please keep it in mind.
EF 4.0 has done a lot to handle the issues that were raised with the previous version of EF. Thinks like transparent lazy loading, POCO classes, code only, etc. EF 4.0 is a much nicer than EF 1.0.
The problem is that it is still a very young product, and the changes that were added only touched the surface. I already talked about some of my problems with the POCO model in EF, so I won’t repeat that, or my reservations with the Code Only model. But basically, the major problem that I have with those two is that there seems to be a wall between what experience of the community and what Microsoft is doing. Both of those features shows much of the same issues that we have run into with NHibernate and Fluent NHibernate. Issues that were addressed and resolved, but show up in the EF implementations.
Nevertheless, even ignoring my reservations about those, there are other indications that NHibernate’s maturity makes itself known. I run into that several times while I was writing the guidance for EF Prof, there are things that you simple can’t do with EF, that are a natural part of NHibernate.
I am not going to try to do a point by point list of the differences, but it is interesting to look where we do find major differences between the capabilities of NHibernate and EF 4.0. Most of the time, it is in the ability to fine tune what the framework is actually doing. Usually, this is there to allow you to gain better performance from the system without sacrificing the benefits of using an OR/M in the first place.
Here is a small list:
- Write batching – NHibernate can be configured to batch all writes to the database so that when you need to write several statements to the database, NHibernate will only make a single round trip, instead of going to the database per each statement.
- Read batching / multi queries / futures – NHibernate allows to batch several queries into a single round trip to the database, instead of separate roundtrip per each query.
- Batched collection loads – When you lazy load a collection, NHibernate can find other collections of the same type that weren’t loaded, and load all of them in a single trip to the database. This is a great way to avoid having to deal with SELECT N+1.
- Collection with lazy=”extra” – Lazy extra means that NHibernate adapts to the operations that you might run on top of your collections. That means that blog.Posts.Count will not force a load of the entire collection, but rather would create a “select count(*) from Posts where BlogId = 1” statement, and that blog.Posts.Contains() will likewise result in a single query rather than paying the price of loading the entire collection to memory.
- Collection filters and paged collections - this allows you to define additional filters (including paging!) on top of your entities collections, which means that you can easily page through the blog.Posts collection, and not have to load the entire thing into memory.
- 2nd level cache – managing the cache is complex, I touched on why this is important before, so I’ll skip if for now.
- Tweaking – this is something that is critical whenever you need something that is just a bit beyond what the framework provides. With NHibernate, in nearly all the cases, you have an extension point, with EF, you are completely and utterly blocked.
- Integration & Extensibility – NHibernate has a lot of extension projects, such as NHibernate Search, NHibernate Validator, NHibernate Shards, etc. Such projects not only do not exists for EF, but they cannot be written, for the most part, because EF has no extension points to speak of.
On the other side, however:
- 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.
- EF is from Microsoft.
Comments
exactly what i think even if i'm not as experienced as you
expecially tweaking...
every need i had (even the more exotic) i quickly found an aswer about how to do in nhibernate...while most of time i've been completely stuck in EF
the only thing i really miss in NH is a goog linq provider
A good post, with some good points! I like the "blog.Posts.Count" .
It is amazing how competition (If EF can be regarded as an opponent?) drives innovation and stop MS software from stagnating!
Roll on NH3.0!
As someone who has worked with NHibernate for only a few hours it seemed to me that the experience of manually creating domain classes and mappings (with FluentNHibernate in my case) was quite manual and the error messages were not that good. This is something that I would write onto the EF4 side of the comparison.
Actually now that I think about it NH probably also has some tools to generate everything from the Database. Maybe this would be a topic for a future post?
Don't remember who said ... "OR/M is the Vietnam of the Coding"... NH is a veteran, EF is young recruit. Unfortunately MS can't leverage OS, if they do life would be easier: designer and integrated tooling by MS, OR/M by NH would be a productive solution.
I do not know if it is different with EF, but I do find some of NH not yet completely perfect, such as
If the ISession throws an exception you should immediately rollback the
transaction, call ISession.Close() and discard the ISession instance.
Certain methods of ISession will not leave the session in a consistent state.
This is very annoying for some scenarios, it would seem that rollback should be more than enough to get back into a pre-error state.
This is something that I was looking for. If you have more info to compare I will kindly appreciate as I use in the Company NHB but at home EF. I still prefer NHB for a business purpose and EF for a 'hobby' purpose.
"Collection with lazy=”extra” – Lazy extra means that NHibernate adapts to the operations that you might run on top of your collections. That means that blog.Posts.Count will not force a load of the entire collection".
EF do this. Or not?
"Collection filters and paged collections"
Is this blog.Posts.Skip(10).Take(10)?
Andrey,
After a rollback, NHibernate has no idea how to resolve any differences between in memory & database states.
Felipe,
No, it will force a load of the entire collection
An additional pro for EF is that the documentation is more organized and error messages are more descriptive.
I still prefer NH though, but it takes a lot of blog-browsing if you have a problem. Conversely, the benefit of that might be that there are a lot of people you can ask questions to.
Could you point me to a resource with more information on: "Collection filters and paged collections" I had tried to do this with NHibernate in the past but I hadn't had any luck.
I think it is an powerful feature that doesn't have much air time, or at least air time that I have seen anyway.
Take a look here and search for CreateFilter:
http://www.nhforge.org/doc/nh/en/index.html
Another major advantage of NH is that it's OSS. I've needed to patch NH several times over the years, to fix a bug or add something I needed. With EF, I'm just stuck.
I think you should explicitly state that only benefits of NHibernate are shown here. Disadvantages are almost untouched at all - even your words about LINQ provider are pretty far from truth; another well-known case is that EF supports change tracking, but NH does not, and this can dramatically affect on performance in set of cases (in fact, you should forget about certain cases in NH at all - just "by design").
So I think it's a good idea to find someone that can make more "independent" comparison of both frameworks. Btw, I feel this must be hard - i.e. any expert that knows both of them, will, likely, be at one of two camps anyway ;)
@alex: what do u mean with 'change tracking'?
i don't understand why for u the nh session isn't tracking the changes (if it's not complicated can u post an example of that special cases)
thanks
@jain
My guess: in NH on transaction commit, NH checks each entity instance to see if it has changed and needs an UPDATE statement to the DB.
EF can keep track of each change for an entity (for example, property was set to a different value) and does not have to check each entity instance at commit.
Not sure though.
Since I have been using NHibernate successfully for several years I am biased. But I think that it will help if MS opens EF like ASP.NET MVC.
I think it makes sense for MS to build their own ORM. It's part of what I like so much about the MS stack - they provide a nice environment out of the box (so to speak).
That said, I'd much rather use NHib. While Oren is a NHinja and doesn't need it, I also like have Fluent-NH. Using, FluentNH, NH, and FluentMigrator (blatent promotion), I can get an app set up pretty quickly and functonal.
I still think EF vs. NH is a silly argument. Most devs who end up using EF aren't going to be interested in NH, and it will work just fine for them for the most part. Those people probably don't read Oren's blog.
(Why does ayende.com's "remember me" checkbox not really remember me?)
@Jimmy - Fully agree that OSS is a big benefit. When I've hit a bug in NHibernate (and they are honestly rare), it's been a few hours to fix and the NH team usually incorporates the patch in under a day. Compare this with .NET Framework bugs (since EF is now ships with .NET) where getting a patch in is a multi-month to multi-year process depending on Microsoft's release cycle.
@Alex - NHibernate has automatic dirty checking whereby it compares the known database state (serialized in a lightweight format in the session) with the current state of the object when the transaction commits. EF uses change tracking and IPropertyChanged notifications to wire your domain object into the data layer. (Haven't looked at their POCO impl lately.) Each technique has its advantages/disadvantages.
The lack of extension points is the first real killer here, I have regularly used nHibernate's extension points for things like custom ID generators. Furthermore nH makes it easy to build extensions because it is OSS and the source code essentially documents itself.
The second is the lack of existing extensions, just taking fluentNH for example. I've already said it before, but when you combine:
Writing domain entities first
Using fluentNH autopersistencemodel
Using schemaexport/update to generate DDL
There is no need or use for graphical designer interfaces.
The reality is despite what people say about the learning curve, using EF is likely to take longer and cause more headaches then NH. The choice really should be clear.
@Felipe, @Ayende
Just to clarify, using the default designer models and not POCOf:
"EF do this. Or not?
"Collection filters and paged collections"
Is this blog.Posts.Skip(10).Take(10)?"
Yes, EF will correctly filter that collection.
And @Ayende, I'm seeing Count() being executed correctly and not loading the entire collection.
SELECT [GroupBy1].[A1] AS [C1]
FROM (SELECT COUNT(1) AS [A1]
NH also has this nice query obfuscation API making the query logic totally incomprehensible to your enemies. Haven't seen anything like that in EF:
ICriteria criteria = Session.CreateCriteria(typeof
(Person), "pers")
DetachedCriteria.For <personaddress("persAddr");
("persAddr.PersonID","pers.PersonID")));
NHibernate.Transform.DistinctRootEntityResultTransformer());
<person() as List <person;
:)
Oops, ran some more tests and see what your talking about. Bad EF, very bad...
John,
I am sorry, but it appears you are mistaken.
The following code:
using (var db = new Entities())
{
}
Will generate the following SQL:
-- statement #1
SELECT TOP ( 1 ) [c].[Id] AS [Id],
FROM [dbo].[Blogs] AS [c]
-- statement #2
SELECT [Extent1].[Id] AS [Id],
FROM [dbo].[Posts] AS [Extent1]
WHERE [Extent1].[BlogId] = 1 /* @EntityKeyValue1 */
rumburak,
There are multiple ways of querying with NHibernate. Choosing the wrong query tool for the wrong task can make it harder to understand what is going on.
The criteria API is meant for programmatic manipulation of the query.
If you have a static query, you should use either HQL or Linq.
I think that biggest advantage of NHibernate is better support for unit testing. EF4 is not designed for testing and it is very difficult to write unit tests for some custom solution based on EF4.
On another hand EF4 has very good designer (most important thing that you need for real world large project) and POCO T4 template based on that designer... I think that is time that you start thinking about making your own designer for NHibernate instead of denying need for designer and code generator. If community wants designer for NHibernate, give them good designer... And third party designers are miles away from EF4 designer except probably LLBGEN 3 that is not yet released and is not free.
Hear Hear, paging doesn't matter, because EF now has something better!
Single / SingleOrDefault with super-efficient TOP 2 for super-sonic-sexy-efficient MS SQL server query, dodge that!
thedatafarm.com/.../a-message-from-your-sponsor...
/end of parody/
NH runs on .NET 3.5 (and Mono), EF 4.0 doesn't
EF is using POCOs, __ but to use change tracking proxies (and not snapshot like comparison), you need to instantiate ALL entities with ctx.CreateObject <t instead of new <t, which is even <inenforced and recommended pattern.
You're glad you went with POCO, Persistance Ignorance and Framework independance, don't you? Screw those "new", there's a better kid in town:)
on the other hand, EF 4.0 means you have a life, NH means you don't.
I promised myself to have a life in 2010... so screw that gazillion query options in NH, I'm fine with ONE (LINQ) and I believe I'll no longer need to wait for updated FNH build/ LINQ provider / any-extension-which-never-gets-to-the-final-stage to work with my other stack....
Like any OSS project, NH world seems like there was never a final stage, all the time one or two parts of the link were in beta stadium...EF when released, will hit 0 bug status and final stamp.
That's awful on skip and take.
Linq to SQL does that properly.
@Radenko
how well does that designer work for you when you have more than one teammember making changes to the domain at the same time? as you surely know, this happens frequently in real world projects and from what i've heard from various people, EF's designer isn't exactly helping things in that situation.
@Davy
You are probably right. That can be problem. I am not saying that EF designer is perfect.
That is not the point here. I am saying that community needs good designer for NHibernate.
I suggest that Ayende make one pool here where we can vote for making designer for NHibernate or not to see what people wants...
@Radenko Zec: if the designer wouldn't support fluent NH, than it would be of no use for me... so far the funny saying is, the "class diagram" is your designer ;)
This is something even EF doesn't have.
You have either code-only approach completely without a designer, or you're with the Designer + T4 templates for POCO generation, but any change to the mappings must happen in the designer (unless you like xml and stuff like that, which I don't).
I doubt the Frans will support FNH, as its API changes pretty frequently...
There was a side-hobby-project of T4 generation L2S->FNH from excellent David Hayden, which imo could be the way for NH...
Altering EF T4 templates to generate FNH mappings shouldn't be a big deal...
www.pnpguidance.net/.../...enerationLINQToSQL.aspx
@cowgaR
Designer must connect to database(if we have database ready) and generate all files that I need without need to write any files manually. You can call it designer or code generator or whatever you want... :-)
EF designer is also similar to class diagram...
@Radenko
I think a designer ( or a code generator ) db driven could work only for an initial snapshot of the code. Unfortunately there is not sufficient information in the database to safely drive the generation process in the entire process lifecycle. Hbm are, even if we don't like xml, the place where the OR/M are described. Plus the hbm has the <meta concept to add custom generation attribute.
@Felix, I agree with you that initial generation is only a quick win. Visual NHibernate ( http://www.slyce.com ) can reverse-engineer hbm files from existing projects. It also safely round-trips code-generation, adding/modifying classes and properties etc where required but not touching your existing code. All your mapping data is read and written to your hbm file(s), which are your master repository of all your mapping data.
EF 4.0 will run on .NET 4.0. NH 3.0 will only run on .NET 3.5 unless I download the code myself and, assuming it works, compile it (I think, please correct me if I'm wrong).
Which is a pain.
Still, I'd prefer NH 3.0 with Linq though (Agree with some of the others, Criteria is so unreadable and hard to get your head around, I do what I shouldn't and parse my own HQL when creating user-controlled run-time queries.....).
Mind you, AFIK you couldn't do that with Linq either
@Gareth
I prefer this one: nhforge.org/.../t4-hbm2net-alpha-2.aspx ( guess why ;) It is terrible ugly, but behave well even in strange mapping ( xEs join / map with complex key ). I hate xml in general, but with a little exercise and teh intellisense hbm are now my friend. To be more related to the topic of the Ayende Post, I don't think the designer is the real gap between NH & EF...
@felix, your project looks good! Related to Ayende's topic, this is exactly a strength of NHibernate compared to EF4: choices. Choices for many aspects eg: caching provider, designers etc. The more choices the better - a strong ecosystem benefits everyone, especially users. I'll reply to you offline, because I don't want to go off-topic, but I do want to say that Visual NHibernate does support all the complex mapping scenarios that NHibernate has, such as mapping with complex keys, and even component keys.
I really think that both are great tools.
Microsoft needto have something stronger than LinqToSql out of the box in VS2010. EF4 is it, and, of course, it will not be as good as NHibernate, which is available for such long time.
However, it is clear that NHibernate need to shape up. There are several different ways to query a database in NHibernate, and this make it very difficult for the beginners, while EF4's LINQ takes a lot of benefits from it.
There are a new LINQ implementation in NH 3.0, sure, but IMHO, what really take NHibernate down is the amount of dependencies on it. It has Antlr, log4net, LinFu/Castle for lazy loading and now, in NH 3.0, we also have the ReLinq framework. That's where EF4 shines. It comes out of the box from the framework.
For web apps this is not a problem, but for simple desktop apps, it is a heavy burden. Maybe the NH team could handle it out. It'll make NHibernate really unbeatable.
I don't understand the 'amount of dependencies' concern. Why is this a problem? Would it help to ILMerge the various assemblies for deployment?
Really Adriano? In the real world, choice is good. One of the biggest problems with the .Net platform, as least how Microsoft defines it, is little choice. The problem with that, is that there are different use cases which require different solutions. Until just recently ... you wanted to do a website - ASP.Net. A website/app? ASP.Net. An app with a browser? ASP.Net. Finally, they got the hint and put out ASP.Net MVC and Silverlight.
As for amount of dependencies: Not really very many. Compare it to Hibernate. As for "working out of the box". Nothing ever really does that. I almost always run into issues when deploying if I cannot control all the dependencies.
"I doubt the Frans will support FNH, as its API changes pretty frequently..."
@CowgaR: not from the start no, but there's also no use for it: you have the model as source and the hbm.xml files as destination (and classes if you want to), so why bother with FNH code as well?
What EF has over NH is documentation, solid examples and a large stream of evangelists speaking at every developer conference there is and pumping out articles around the clock. The NH world never seemed to take that as important but it IS important: a developer is payed to solve a problem for his client, not to hunt down docs on blogs or other non-trivial places.
About choices: in general more choices means the chances that there is an option which fits how you want to work is higher. The downside of more choices is that to determine which choice is the right one takes more effort, time and it depends on the solidness of examples and documentation to be able to choose which option to take. As NH sucks in that department (and please, don't come with excuses, it does suck in the documentation department. If you want to know how big it sucks in that department, take a tour in the DDL SQL producing docs for _N_hibernate and learn how great it can generate ... java classes. huh?), and at the same time has many options, it's not really an advantage to have.
Simply because: you're not payed to dig into how the tool you want to use works, but to USE it. you're not payed to write big chunks of code to get to the database, you're payed to solve a problem which uses the database, i.e. the code which uses your model classes, hbm.xml files etc.
Not everyone is a .net rockstar, most of the developers out there barely know how to code their way through the day. If you want to make THEM use NHibernate, you really have to put more effort into docs, examples and a more streamlined way of using the toolkit. For example, it shouldn't be necessary to hunt down where the 'current' contrib library is, it should be installed with nhibernate, as it's actually something which should be part of the library, as it makes using the toolkit way easier. Sure, some daredevils with too much time on their hands write their own contrib equivalent code, because they think they're better. Chances are that 99% of the potential users don't do that, so why targeting that 1% who has a big mouth but actually can do very little?
I'm not saying EF 4 is the best there is, on the contrary. It's just that in the big bad world out there, NH means little to nothing because the majority has no time and doesn't want to spend a lot of time on learning how it works by spending a lot of time in the google search box. Do these people miss some features EF 4 doesn't have? well, they won't use them (as they're not there) but I'm not sure if they'll miss them. They'll just use another type of query for example.
For counting records there are better ways to do that in EF. L2E and eSQL are 2.
Plus the EF Model GUI designer is a tool that improves productivity and that should not be excluded from you list of EF advantages in my opinion.
EF generates a lot of code but you can change all that by the means of the T4 templetes. Not to mention that the EF team has made a huge effort to support POCO scenarios and Code Only scenarios also.
When you create a topic like this you must be willing to see the advantages and disavantages on both sides, not only one. I dont think thats the case here.
@Frans, I hope that when (antlr based) LINQ will be released, the query documentation for EF will match documentation on NH, e.g. once you know LINQ you know how to work with NH.
Learning will be improved (on query level) where apart for studying few NH-specific LINQ expressions you'll fine without digging to "unsafe" HQL or "unreadable" ICriteria or any other query lng that NH offers...
I know it sounds stupid to have the designer __and fluent mappings, but personally I like FNH not just because of fluent mapping it provides.
Makes things easier for me, from fluent NH configuration (just 3 basic functions with intellisense) to start NH project, to unit testing CRUD of your entities with just one simple method.
Then if anything is wrong, glance to ClassMap file will show you what's wrong very fast - as it is completely readable (conventions over configurations) and only important things are stated (the "irrelevant/repetitive" can be either automapped or inherited), so not ultra verbose-ness of hbm.xml files. Want to do corection? Intellisense for you...
Then there is refactoring, I know you'll handle it with the designer, but for me, another member of the team can handle it with notepad and search & replace ;)
The most logical way for me is to keep working with FNH due to its many advantages, and find a way to generate entities/update schema with whatever designer that is avaiable, say even EF one. Then simply run T4 scripts and continue using FNH project for improved TDD.
The problem is, any change to mapping files that happens in FNH won't be reflected in the designer, so I guess I need to choose a side :)
"It's just that in the big bad world out there, NH means little to nothing ...."
Says the guy making a living off his own commercial tool.
@cowgaR: if you have a bunch of classes already and suddenly the requirement comes up to persist them, it's perhaps easier to go for FNH. However, if you start with a db or from scratch, you can leverage the source of what you're using in code: the abstract entity model. That's projected on relational models and classes. The advantage of this is that a single change in the model can have effects in both sides and perhaps multiple results instead of the one you had anticipated. (example, change a 1:n into a 1;1)
changes happen and they always have a side effect. My opinion about that is that if you change at the source (and that's not C# code, but the real source of your entities, tables and mappings: the abstract entity model, i.e. the theory why an entity 'customer' exists for example) and let the projections of that source be influenced by that source, you've to deal with the least amount of side effects resulting from a change.
I don't see how a string-using mapping system (which requires you to write dummy classes for mappings, while that was considered a bad thing in other situations?) like FNH can be less work than a designer which is meant to be a helping hand for managing the mappings and both sides which are mapped ;). But of course, everyone's situation is different and what works for person A is a productivity killer for person B.
""It's just that in the big bad world out there, NH means little to nothing ...."
Says the guy making a living off his own commercial tool. "
@Rob Jennings: ... and your point is? I'm not capable of forming a valid opinion? Or was it that you couldn't stand the negative tone towards NH? Tssk.
Ever occurred to you I might have more insight in this market than most people replying to this post? You can make a good living in a niche market, and O/R mapping is still a niche market. NH is pretty big among a certain group of developers, but the vast majority of the .NET developers has never used it and likely never will. The simple reason is that they have used datasets till now and will likely move to what MS offers in the (near) future. Add to that the massive marketing and other communication material MS will push through their throats and it doesn't look that great for the comparison of EF vs. NH. (wasn't that the subject?)
If you think that's gobbledygook from a biased O/R mapper developer who (boo!) sells licenses for the code he worked on for 8 years straight, so be it, it's your opinion. But ignoring reality doesn't make it go away, Rob. If the NH team is clever it puts more time in public awareness of the toolkit, make it more accessible, better docs etc. and less time in tiny edge-case features no-one but themselves will ever use (and that's also partly because no-one but themselves knows about the existence of these features).
Funny how much hatred every time bubbles upwards when someone pokes a small stick into NH. That's not helping you nor your beloved framework. If all that energy was put in a better linq provider and better documentation, NH would have had both by now already. Then it would have been a valuable alternative to the two free frameworks from MS.
But now? Why would anyone not use EF if you want a free framework? Because of some edge-case paging query you can write differently in several ways? Or, if you have MS that much, why not use EUSS? Also free, and IMHO superior to NH in many ways.
@Frans
Well said, I've mentioned it in comments before (and had a few people agree) that the biggest barrier to entry with NH is the lack of cohesive documentation. It's just very difficult to get started, where as other "less mature" products are a snap.
Gotta agree with Frans on this one. The entry bar for NH is pretty high, sure it can do amazing thing but the question is how to do it.
I think the biggest advantage and also draw back to NH is that it's open source. There seems to be a general attitude for most opensource software is that if you don't like something fix it. Which I don't blame them, after all it's free, the dev don't get pay to fix it. It's nice enough of them to release it in the first place. But EF is also free.
Since not everyone know how to, have the time or willing to fix the documentation. Combing all the criteria above the chance that it will fix is pretty small. Surely the lack of documentation is getting better for NH but it certainly happen at a pretty small pace. Though to be fair ASP.Net MVC documentation is also seriously lacking at this point.
Though I must point out, NH mailing list is pretty active so if you are stuck, it's a good place to go to...
@Frans
I agree with the some of your statements, namely the issue with NH documentation. It is the single biggest problem with NH. And not just documentation, but 'up to date' documentation. For example, the NHibernate in Action book covers what version of NH? 1.2? How much has changed between that version and the current? That book took 'forever' to be released. Not too mention v3 is on the way....
That said, my issue is that in this post and other posts you make on this subject, you cast a very negative light on NH, I believe it is (understandably so) because you are biased. Sorry, but I have yet to see a real alternative to NH for the 'aware' developer. I could care less about the dataset crowd, they will always be there and let them do what they do.
@Rob: you meant EF not NH right?
@Frans: saw your video on LLBLZHTBLEHGen designer, niceee...superb ideas in quick mode, but infantile presentation on interface all over (and complicated as hell, remember, we do have context menus), is really missing elegant touch of other designers that are avaiable for various competing products.
I agree with most of your points, I guess the 2010 era will be era of RAD/Designers/Scaffoldings like we've never seen before...time to try EF v4.0?
@Ayende: will EF profiler support EF v4.0? (if no, +1 to NH, if yes, then I guess.... ;-)
cowgaR,
Yes, EF 4.0 is fully supported right now
The only major thing I think EF has going for it, and why I might choose EF 4 over NHibernate is the ADO.NET Data Services. One .svc file creates a REST CRUD API for your entire model.
I haven't looked into it but does anyone know of a way to do the same with an NHibernate model? I would love to play around with that.
Ryan,
You can create the same with NHibernate, certainly.
@Rob Jennings
I must say I don't really think Frans' posts in this forum have been all that negative, his initial comment in this thread was is just an honest statement about the barriers to entry for NH (which nobody is really disagreeing with).
It's very easy to throw on the "Oh he's just biased" glasses, but reading the actual comments I really don't see it.
@Frans,
Thanks you for defining someone a "daredevil", it makes me feel younger. Less polite is the "big mounth",but I know, is the price we have to pay for you sharing your wisdom. but is Actually the 'personal' contrib version i'm talking about is on the offical contrib version. I do not have so much useless time to spent, this is the reason my work is for sure a little monkey in comparison to your. I just did it cause NH give me a lot of productivity and I would like to pay back something. Basically I'm really surprised on seeing so many people complaining for documentation, the site NHForge is plain of whatever you need to starup with NH. Plus you have the source code. Plus you have a lot of people helping you basically for free ( Fabio Maulo one of the best,Ayende as well). Furthermore, the fancy designer with fancy colored boxes is a "must have" that fail as soon the model pass the 15 entities...
"That said, my issue is that in this post and other posts you make on this subject, you cast a very negative light on NH, I believe it is (understandably so) because you are biased. Sorry, but I have yet to see a real alternative to NH for the 'aware' developer. I could care less about the dataset crowd, they will always be there and let them do what they do."
The owner of this blogpost is also biased, did you accuse him of the same thing? face it, everyone in the (very small) O/R mapper developer world is biased. Very biased actually: they all think their own work is the best. IMHO that's perfectly fine, as otherwise they wouldn't do what they're doing, eh? ;)
About alternatives: you shouldn't look at it that way: if you look for alternatives you end up with the same vision as the O/R mapper developers themselves: they know how other frameworks work, but what they work on is still superior. If you look for an alternative for NH, the alternative will need to be NH but... not NH. Otherwise you've to adapt to the differences between the other framework and NH and every other O/R mapper has differences with NH like any other O/R mapper has with any other O/R mapper, simply because for each framework the developers have chosen to do things slightly differently, for whatever reason.
So I think you won't find an alternative for NH if you stay in that mindset. You should look at it from a different angle: what do you really want to do? Bottom line is that you want to solve the client's problem. Any other thing is less important. So if the client needs a db driven website, you thus have to communicate with the DB. You can do that a million ways, but at the end of the day, what's important is that you get the data out of the DB and you get the new data into the DB with the least amount of YOUR code (as that gives less maintenance). If you look at it that way, you just adapt to how the framework at hand works and you use it the way it is intended. Not the way NH works (unless it's NH ;)), but the way the framework is meant to be used. If you do it that way, each framework will work properly with perhaps a few features not ideally working, but that's true for every framework.
"@Frans: saw your video on LLBLZHTBLEHGen designer, niceee...superb ideas in quick mode, but infantile presentation on interface all over (and complicated as hell, remember, we do have context menus), is really missing elegant touch of other designers that are avaiable for various competing products."
@cowgaR: I don't follow you. There are several ways to do the same thing, and none of them is complicated, as all what you have to do is at the same spot and actually more productive than Drag n Drop designers with a big canvas which require you to fiddle in property grids or popup dialogs which are also complex and scattered all over the place. Context menus are there, the designer just isn't focused on the 'big canvas in a big picture' idea, as that in general doesn't really work in models which are bigger than a few entities.
Quickmodel is just another way to define entities really quickly, e.g. during an interview. See it as mind-mapping but with an entity model designer instead. It's a little rough around the edges, as I wrote it in just 3 days (the development, thinking phase was about a week).
The idea of a designer is first and above all to be a general portal towards the model and its mappings onto meta data. So you should be able to view it (see the search video) in various ways even if you don't get the views on it in the way you want to, modify it and extend it, and with every step you as the developer should be in control and the designer should get your back when you scr*w up. Otherwise, it's just a glorious toy which does the same thing as notepad but now with a gui.
But we can discuss this off-list if you want. I'm really interested in why you thought it's 'infantile' presented and way too complex.
These spats are the main reason I read this blog. Marvellous.
@Frans
"The owner of this blogpost is also biased, did you accuse him of the same thing?"
True. But then again, the author's contributions to software that I use, his blog posts, talks, etc... have made a big difference in my daily development life. So I guess you could say I am biased too ;)
This is going off topic, but you made some comments that I found interesting:
"So if the client needs a db driven website, you thus have to communicate with the DB"
Indeed. I get the feeling you are implying that the time required to accomplish this goal with NH is much greater than other frameworks? If we are talking a legacy DB here than yes. I always believe in choosing the right tool for the job and would not use NH with some POS legacy DB. However, especially with the usage of fluent NH, my team is VERY productive with NH. It allows us great control and to be very expressive when working with our object model.
So, what are talking about here? I don't quite get your point about my "mindset" either. I am very objective. To be honest, I avoided NH for years and have used Subsonic, Ibatis, Linq2Sql, etc. After taking the initially painful plunge to NH, I can't believe what I was missing.
@Rob Jennings
"I get the feeling you are implying that the time required to accomplish this goal with NH is much greater than other frameworks?"
No not at all :)
I meant: with NH you do it using methodology A, and using another O/R mapper you do it using methodology B. Just because NH uses A doesn't mean B is bad, it's just different, however has the same end result: you can communicate in your code with the db with a minimum amount of code to write.
So focusing on 'A is good because NH does A' is not the right way to look at things. You should look at it as: 'I need to use a DB. I can use methodology A, B and several others. Pick one'. That way, you make the way you want to work with the DB the reason you picked a framework, and also makes it easier to debate O/R mappers, as there's no real 'wrong' or 'right', just different ways to do the same thing
@cowgaR: I'll mail you tomorrow (saturday) :)
@Frans
"That way, you make the way you want to work with the DB the reason you picked a framework, and also makes it easier to debate O/R mappers, as there's no real 'wrong' or 'right', just different ways to do the same thing"
Agreed.
Now, can we please agree that NHibernate > EF??? ;)
@Rob: "Now, can we please agree that NHibernate > EF??? ;)"
Nobody is actually saying that NH <= EF! It's just that the comparison was biased and incomplete.
In SQL centric logic projects where complex business transactions are handleded via stored procs, all ORM tools (EF4, NHibernate, Linq2SQL, Viewsonic...) sucks. Does any one know the work around/solution to tackle da scenarios....
Hassan,
You can do it, but as you noted, it isn't pleasant. My general recommendation is to avoid doing this if at all possible, and use something like iBatis.NET (or something else that is working at the SQL level) to handle things.
Exactly. NH always has to perform linear scan on commit to extract the changes. EF does not.
Consequence: slow flushes requiring the time proportional to data accessed in this session. Note that such flushes can be frequent - e.g. they may happen before each query. So even if query fetches just one object, its cost can be proportional to all the the data you already fetched.
Frans and others have a point - NH is ridiculously difficult for your average developer.
A few years ago I had decided my team would utilize NH for a new project. I had one senior developer, and 2 junior developers at the time, and they struggled for 2 weeks to get anything decent. Most junior .NET developers (over 50% of all .NET programmers) don't really understand object oriented design, so NH is a HUGE hurdle.
For my team, it just didn't click, and seemed like a massive amount of work to them. Their minds worked linearly, and they could produce solid code as long as it was more procedural.
For us the answer was LLBLGen. I'd personally have loved to use NH instead, and utilize it at home for projects, but it definitely is for far more skilled developers than average. Plus, my project at work has hundreds of tables and thousands of fields ... llbl lets the team think about the database and business logic, all the persistence code and mapping is handled for them without any concern on their part.
I am in the process of trying to find the right ORM tool to use for a project that I am currently working on. Yes, I am one oh those .NET developer that just want to grab something, find documentation and go. NH has been difficult to find and good documentation to get started. I am having to search in different places to simple start accessing my database. While on the other hand, EF I can go to the bookstore, grab a book off the shelf and be up and running in the matter of minutes (heck I do not even have to go to the store - I can get it online).
With that being said, I would love to use NH if the performance is better than EF, but as mentioned numerous times above, it is a headache to get started using NH. Yeah, I know I could eventually figure out what needs to be done to get started with NH, but in a time-crunched society that we live in, I just do not have the time to invest in finding all the information to get it going. I think I will give LLBLGen a shot since I can go to the site and get all the information I need to get started.
Michel - LLBLGen really excels when you are in a "Database first" mentality, at least up through v2.x. You can literally be up and running with an existing database in 5 minutes, and coding decently complex stuff in ~an hour. However, if you are looking for in-memory persistence/testing or domain driven design, it's probably not your best solution.
NH is great for a veteran (rockstar?) developer who follows Agile methodologies and wants an ORM that will facilitate this. LLBL is for someone who wants to be up and running fast with a tool that is easy to use, but at the same time full featured.
Wow excelente blog, Felicidades...
The biggest NH disadvantage in my case comes specifically from the fact that NH is OSS. I have made preparations to use NH in one of my projects only to have to tear down later when I learned the client company enforces a policy advising against the use of open source software due to privacy, security and supportability concerns. This was not even up for discussion in any circumstance. Having NH out of the picture we had to use commercial products such as EF and LLBLGen.
We picked EF (only for cost effective reasons).
Real world scenarios not always have to account only for the best tool out there but often involve a combination of factors that determine the final choice.
One other comment I have that I think wasn't already said in here is that EF follows a MS road map which will eventually address shortcomings and potentially close the current gap with NH, but more importantly it will promote integration with other MS products such as Reporting Services (SSRS) and SSIS (maybe?) which will open the ORM door to other types of (MS) applications where NH cannot be used.
good post Ayende. But one thing still bugs me about NHibernate.... XML. I've been digging in the java side of the world as of late, and I really like the attribute oriented approach to OR/M. I mean it seems as if much of the typing that's needed in the hbm files are simply redundant information that can be pulled from the .cs (or .java) file instead.
i.e. why should i have t to type out the names of each of my properties twice? Furthermore, what about refactoring? When i change field names etc, I then also have to go back and do the same thing in my hbm files. Any plans to implement this approach in NH?
Ben,
There are many ways to set the mapping without using the XML.
ActiveRecord, NH attributes, Flunet NH
EF is going to be a winner in a year if it isn't one already. What people still don't understand is that you should be spending time on business logic not DAL, which is where i am with NHibernate on almost every single project. Unless you work on open-source solutions, NHibernate is unproductive in real-world where you have time constraints and deadlines. I don't want to go through manuals to figure out every single mapping intricacy i run across. I just want to build my model and feed it to NH. You don't get that with NH, but you do with EF and this is where it wins as an out-of-the-box solution. IMHO, NH was designed for Open-Source community by Open-Source community. Instead of putting so much time on making it the best there is, i'd like to see some tools to get this thing to work with the real world.
Comment preview