Ayende @ Rahien

Dave commented on NHibernate vs. Entity Framework 4.0

Sun, 28 Feb 2010 16:38:53 GMT

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.

Ayende Rahien commented on NHibernate vs. Entity Framework 4.0

Fri, 29 Jan 2010 19:28:16 GMT

Ben, There are many ways to set the mapping without using the XML. ActiveRecord, NH attributes, Flunet NH

Ben commented on NHibernate vs. Entity Framework 4.0

Fri, 29 Jan 2010 17:31:06 GMT

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?

somn commented on NHibernate vs. Entity Framework 4.0

Wed, 27 Jan 2010 05:34:51 GMT

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.

williams commented on NHibernate vs. Entity Framework 4.0

Thu, 21 Jan 2010 14:48:08 GMT

Wow excelente blog, Felicidades...

Josh commented on NHibernate vs. Entity Framework 4.0

Mon, 18 Jan 2010 19:31:16 GMT

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.

Mitchel commented on NHibernate vs. Entity Framework 4.0

Mon, 18 Jan 2010 17:40:26 GMT

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.

Josh commented on NHibernate vs. Entity Framework 4.0

Mon, 18 Jan 2010 06:29:49 GMT

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.

Alex Yakunin commented on NHibernate vs. Entity Framework 4.0

Sat, 16 Jan 2010 09:33:59 GMT

> EF does not have to check each entity instance at commit 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.

Ayende Rahien commented on NHibernate vs. Entity Framework 4.0

Wed, 13 Jan 2010 14:46:16 GMT

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.

Hassan commented on NHibernate vs. Entity Framework 4.0

Wed, 13 Jan 2010 09:37:14 GMT

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....

chris commented on NHibernate vs. Entity Framework 4.0

Wed, 13 Jan 2010 02:57:09 GMT

@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.

Rob Jennings commented on NHibernate vs. Entity Framework 4.0

Sat, 09 Jan 2010 14:22:48 GMT

@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??? ;)

Frans Bouma commented on NHibernate vs. Entity Framework 4.0

Fri, 08 Jan 2010 19:34:35 GMT

@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) :)

Rob Jennings commented on NHibernate vs. Entity Framework 4.0

Fri, 08 Jan 2010 13:01:17 GMT

@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.

Jon Canning commented on NHibernate vs. Entity Framework 4.0

Fri, 08 Jan 2010 10:13:00 GMT

These spats are the main reason I read this blog. Marvellous.

Frans Bouma commented on NHibernate vs. Entity Framework 4.0

Fri, 08 Jan 2010 09:24:13 GMT

"@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.

Frans Bouma commented on NHibernate vs. Entity Framework 4.0

Fri, 08 Jan 2010 09:15:53 GMT

"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.

Felix commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 20:53:20 GMT

@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...

Andrew commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 19:25:17 GMT

@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.

Ayende Rahien commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 16:37:04 GMT

Ryan, You can create the same with NHibernate, certainly.

Ryan Westphal commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 16:33:59 GMT

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.

Ayende Rahien commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 13:39:33 GMT

cowgaR, Yes, EF 4.0 is fully supported right now

cowgaR commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 13:37:03 GMT

@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.... ;-)

Rob Jennings commented on NHibernate vs. Entity Framework 4.0

Thu, 07 Jan 2010 12:58:05 GMT

@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.

firefly commented on NHibernate vs. Entity Framework 4.0

Wed, 06 Jan 2010 22:04:28 GMT

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...

Andrew commented on NHibernate vs. Entity Framework 4.0

Wed, 06 Jan 2010 18:32:51 GMT

@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.

Frans Bouma commented on NHibernate vs. Entity Framework 4.0

Wed, 06 Jan 2010 13:15:55 GMT

""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 Bouma commented on NHibernate vs. Entity Framework 4.0

Wed, 06 Jan 2010 12:58:45 GMT

@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.

Rob Jennings commented on NHibernate vs. Entity Framework 4.0

Wed, 06 Jan 2010 12:54:25 GMT

"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.