Why nHibernate [modified]
-
Everyone else has gone into the why's and wherefore's of using an ORM, so I'll just put in my anecdotal experience. We use nHibernate. If you have a project already started, then back-porting it to nHibernate is a cast-iron b*tch. Don't bother. If you're starting from scratch, though (i.e. you're creating everything from the DB on up), then nHibernate makes things pretty easy. Where it really shines, though, is when one of those designed-from-the-ground-up-with-nHibernate systems needs to get updated to add a column or six to various tables/entities/screens -- nHibernate makes that drop-dead simple. I've had to add fields to applications throughout my career as an internal IS dev, and I've used every conceivable .NET-based data access technology out there - hand-rolled ado.net, MS App Blocks, Datasets (typed and untyped), Linq to SQL, Entity Framework (the early versions), and finally nHibernate, and I can tell you on no uncertain terms, adding (or removing or otherwise altering - think refactoring columns to a FK-related table) data fields to an app is light years easier with NH than with any of the others.
Yeah and you can *always* tell an app that uses code generation and a framework like that because the UI is almost a mirror of the database completely throwing out the window all the modern principles of task oriented design. Those tools give you an app that looks like it was designed by an engineer not a designer.
There is no failure only feedback
-
Everyone else has gone into the why's and wherefore's of using an ORM, so I'll just put in my anecdotal experience. We use nHibernate. If you have a project already started, then back-porting it to nHibernate is a cast-iron b*tch. Don't bother. If you're starting from scratch, though (i.e. you're creating everything from the DB on up), then nHibernate makes things pretty easy. Where it really shines, though, is when one of those designed-from-the-ground-up-with-nHibernate systems needs to get updated to add a column or six to various tables/entities/screens -- nHibernate makes that drop-dead simple. I've had to add fields to applications throughout my career as an internal IS dev, and I've used every conceivable .NET-based data access technology out there - hand-rolled ado.net, MS App Blocks, Datasets (typed and untyped), Linq to SQL, Entity Framework (the early versions), and finally nHibernate, and I can tell you on no uncertain terms, adding (or removing or otherwise altering - think refactoring columns to a FK-related table) data fields to an app is light years easier with NH than with any of the others.
Vark111 wrote:
I've had to add fields to applications throughout my career as an internal IS dev, and I've used every conceivable .NET-based data access technology out there - hand-rolled ado.net, MS App Blocks, Datasets (typed and untyped), Linq to SQL, Entity Framework (the early versions), and finally nHibernate, and I can tell you on no uncertain terms, adding (or removing or otherwise altering - think refactoring columns to a FK-related table) data fields to an app is light years easier with NH than with any of the others.
Hmmmm... Do I understand you correctly? You were changing table from app? What for? Is that even possible? If DB was in some way changed and app have to change to i just started from deleting tables from .dbml (SQLinq) files and adding them once again. Voila! They had changed structure appropriate to changes in DB. Compile and you can use that. Am i wrong?
In soviet Russia code debugs You!
-
Judah Himango wrote:
If you don't know what ORMs are
I know what they are. I just don't understand why use external to .net nHibernate instead of SQLinq. Oh... maybe nH support defaults constraints? And have everything else that have linq? That would certainly convinced me to change ORM. I hate that linq compile object someTable{someCol=1} to 'Insert into someTable (someCol, someOtherColWithConstraintOrDefault) values (1,null). :(
In soviet Russia code debugs You!
n.podbielski wrote:
nHibernate instead of SQLinq
You mean LINQ-to-SQL? That product was dropped by MS. Entity Framework? That improved recently, but it's still years behind NHibernate as far as maturity and functionality go.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango -
n.podbielski wrote:
nHibernate instead of SQLinq
You mean LINQ-to-SQL? That product was dropped by MS. Entity Framework? That improved recently, but it's still years behind NHibernate as far as maturity and functionality go.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah HimangoJudah Himango wrote:
You mean LINQ-to-SQL? That product was dropped by MS.
Yeah... that answer surely convinced me. :) Heh...
In soviet Russia code debugs You!
-
fat_boy wrote:
'know'
Its a trickky one, a silent 'k'.
Jeeez... Did you heard anything about mistakes? Everybody make them, you too. ;P Anyway thanks for pointing it out. It's correct now. You should be happy. ;P
In soviet Russia code debugs You!
:) Yeah, I am trying to correct you without sounding critical. Its difficult! :) I get it with French. I actually know that long term, if I am going to learn the language fluently, that I am corrected, but it can feel like criticism sometimes.
"If climate has not "tipped" in over 4 billion years it's not going to tip now due to mankind." Richard S. Lindzen, Atmospheric Physicist, IPCC "It does not matter who you are, or how smart you are, or what title you have, or how many of you here are, and certainly not how many papers your side has published, if your prediction is wrong then your hypothesis is wrong. Period." Professor Richard Feynman
-
"With this framework I can develop a framework to develop applications" stolen from the old quote: Software Engineer, a person who when presented with a hammer states, with this hammer I can design a tool to drive nails There is a delusion in the business software world that writing to a database is hard and that scalability is a challenge. Of course, when I see code like Int32.Parse(someValue.ToString()) where some value is itself an int, I am not really surprised at this delusion.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
I wouldn't say that people in the business software think it's "hard" to write to a database... It's more that they don't want to write sql anymore when they don't need to. For basic CRUD operations and filtering, sql can be generated through code quite easily. That's also what a lot of people did: write code that generates sql. Which they could go and change whenever there were db changes. Or worse: not write such sql generating code and then go and change every single relevant query in the data layer whenever the db changes. Clearly, this is not a good way to do it. ORM is the answer to that. Now you don't need to care. You change the db, your mapping and entity and you're done (unless your change is breaking stuff off course, but that's unavoidable). So ORM's, imo, definatly are the way to go in typical line of business apps. However, I'm not a big fan of nHibernate. I think the querying system is not intuitive. It could have been a lot more "user friendly". I oftenly feel like it's unnecessary complex. But I still prefer it over msft's entity framework. Actually, I prefer the ORM that we wrote ourselves, but that's another story ;P
-
Yeah and you can *always* tell an app that uses code generation and a framework like that because the UI is almost a mirror of the database completely throwing out the window all the modern principles of task oriented design. Those tools give you an app that looks like it was designed by an engineer not a designer.
There is no failure only feedback
I disagree. Sure, there are apps to be found like that, but in those cases it really wouldn't matter that much if nhibernate was used or not. That's more an architectural/system design problem then anything else. Last time I've checked, when data is retrieved from the database it ends up in the business layer. From there it can go anywhere, under any form. Making your GUI models look exactly like your db diagram has nothing to do with your data accessing technology and everything with not knowing the first thing about UI design. Unless off course, you were actually asked to do it that way.
-
Vark111 wrote:
I've had to add fields to applications throughout my career as an internal IS dev, and I've used every conceivable .NET-based data access technology out there - hand-rolled ado.net, MS App Blocks, Datasets (typed and untyped), Linq to SQL, Entity Framework (the early versions), and finally nHibernate, and I can tell you on no uncertain terms, adding (or removing or otherwise altering - think refactoring columns to a FK-related table) data fields to an app is light years easier with NH than with any of the others.
Hmmmm... Do I understand you correctly? You were changing table from app? What for? Is that even possible? If DB was in some way changed and app have to change to i just started from deleting tables from .dbml (SQLinq) files and adding them once again. Voila! They had changed structure appropriate to changes in DB. Compile and you can use that. Am i wrong?
In soviet Russia code debugs You!
No, not changing from the app - a recompile is needed, and you are correct in that Linq to SQL and EF both make it easy to just drag the table over to regen the entities. However, what if the column you're adding is in a table that's different from the entity you want to add it to? I rejected Linq 2 SQL and EF a while ago not because of the ease of changing entities, but because of the inherent inflexibility of having to make my entities match my table structure. That works fine for version 1 of an app. Not necessarily so good for version 6. (To be fair I understand that the current version of EF no longer has this problem, but I haven't used it recently so I can't comment)
-
Just today I added a tiny baseclass implementing the whole circus around IDisposable and used it to clean up the Dispose() of some of the entities. No big deal at all. Until NHibernate noticed that some entities now had a property that was not declared as virtual. It kept on whining about this and continued to throw exeptions during initialisation. There is no way to tell it to stick with the properties I have mapped and keep clear of stuff I don't want it to put its nose in. And it's no fu**ing Java, so not everything must be virtual. NHibernate must be female. It keeps on nagging and can't accept that some things are none of its business.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011If you don't like it, you most likely don't need it. Luckaly, there are plenty of other solutions for you to choose from. Properties must be virtual in order to allow functionality that uses AOP. Like lazy loading for example. If you ever worked on enterprise grade solutions, you probably noticed that loading an entity from database complete with entire graph of stuff connected to it, is not just a performance hit, but a complete show-stopper.
-
I disagree. Sure, there are apps to be found like that, but in those cases it really wouldn't matter that much if nhibernate was used or not. That's more an architectural/system design problem then anything else. Last time I've checked, when data is retrieved from the database it ends up in the business layer. From there it can go anywhere, under any form. Making your GUI models look exactly like your db diagram has nothing to do with your data accessing technology and everything with not knowing the first thing about UI design. Unless off course, you were actually asked to do it that way.
BubingaMan wrote:
Last time I've checked, when data is retrieved from the database it ends up in the business layer. From there it can go anywhere, under any form.
Wikipedia: "NHibernate's primary feature is mapping from .NET classes to database tables" (emphasis mine) A well designed business layer mirrors the *tasks* that the user needs to accomplish. A code generated business layer off a database mirrors the *data* that the user needs to deal with. Trying to shoehorn a datacentric business layer into a task centric ui layer is problematic to put it mildly. A task oriented app with a carefully, hand designed, business layer that is often entirely divorced from the actual data storage and tables results in happy users that will say the app is so easy to use and they don't have to think about anything to use it because it follows their real world thought processes. Task oriented apps are a thing of beauty, data oriented apps not so much. If you start with a data oriented business layer you end up writing a *lot* of code above the business layer (often in the UI layer) to accomodate all the business rules and tasks the user needs to perform, exactly the wrong place to do it. The lower you can have the tasks and business rules the less code needs to be written above and when it comes to multiple interfaces like web and windows and services you end up replicating that code over and over. Professional programmers who take their craft seriously do not use code generators for anything of consequence.
There is no failure only feedback
-
If you don't like it, you most likely don't need it. Luckaly, there are plenty of other solutions for you to choose from. Properties must be virtual in order to allow functionality that uses AOP. Like lazy loading for example. If you ever worked on enterprise grade solutions, you probably noticed that loading an entity from database complete with entire graph of stuff connected to it, is not just a performance hit, but a complete show-stopper.
Believe me, I know. That is exactly what this application is about. The entities mapped over every single table in the database and the application serializes them to XML for downloads. Not just a few. Downloads of more than 300000 entities are not uncommon. In our tests it even had to handle more than 1.4 million in one single download, just in case some fool decides to download the entire database. The show stopper indeed was NHibernate. Memory consumption went over the roof, even with stateless sessions and everything else the documentation would tell us. So we threw NHibernate out by replacing the resource access layer with a traditional one which uses stored procedures. Also, we took a little more control of the disposal of the entities and behold - reasonably low memory consumption without any tendency to crash the server. It now can even prepare several downloads in parallel. Since November it has been in productive use and not failed to put together one single download. I really do not think that NHibernate was made to handle such things. But perhaps I give it another chance when I make someone's homepage :)
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
No, not changing from the app - a recompile is needed, and you are correct in that Linq to SQL and EF both make it easy to just drag the table over to regen the entities. However, what if the column you're adding is in a table that's different from the entity you want to add it to? I rejected Linq 2 SQL and EF a while ago not because of the ease of changing entities, but because of the inherent inflexibility of having to make my entities match my table structure. That works fine for version 1 of an app. Not necessarily so good for version 6. (To be fair I understand that the current version of EF no longer has this problem, but I haven't used it recently so I can't comment)
Vark111 wrote:
However, what if the column you're adding is in a table that's different from the entity you want to add it to? I rejected Linq 2 SQL and EF a while ago not because of the ease of changing entities, but because of the inherent inflexibility of having to make my entities match my table structure. That works fine for version 1 of an app. Not necessarily so good for version 6.
Crap! I am too unexperienced :) and that is why i am probably so cheap :( So you are using nH because it is much more flexible?
In soviet Russia code debugs You!
-
Believe me, I know. That is exactly what this application is about. The entities mapped over every single table in the database and the application serializes them to XML for downloads. Not just a few. Downloads of more than 300000 entities are not uncommon. In our tests it even had to handle more than 1.4 million in one single download, just in case some fool decides to download the entire database. The show stopper indeed was NHibernate. Memory consumption went over the roof, even with stateless sessions and everything else the documentation would tell us. So we threw NHibernate out by replacing the resource access layer with a traditional one which uses stored procedures. Also, we took a little more control of the disposal of the entities and behold - reasonably low memory consumption without any tendency to crash the server. It now can even prepare several downloads in parallel. Since November it has been in productive use and not failed to put together one single download. I really do not think that NHibernate was made to handle such things. But perhaps I give it another chance when I make someone's homepage :)
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011hehe :) I don't think any ORM solution will be good for such thing. If you find one I'd like to hear about it :)
-
n.podbielski wrote:
because nHibernate work with Java to
nHibernate is a port of Hibernate for Java, they are not interchangeable. nHiberate came before most of the other tools were available, or mature enough, so a lot of companies already have an investment in the tool.
I know the language. I've read a book. - _Madmatt
This is a good, concise answer. I'm not sure why somebody 3-voted it.
-
Vark111 wrote:
However, what if the column you're adding is in a table that's different from the entity you want to add it to? I rejected Linq 2 SQL and EF a while ago not because of the ease of changing entities, but because of the inherent inflexibility of having to make my entities match my table structure. That works fine for version 1 of an app. Not necessarily so good for version 6.
Crap! I am too unexperienced :) and that is why i am probably so cheap :( So you are using nH because it is much more flexible?
In soviet Russia code debugs You!
n.podbielski wrote:
So you are using nH because it is much more flexible?
Exactly this. And don't get too down about the experience. You just keep doing what you're doing until you run into issues, then you change something. That's the way I eventually got to nH.
-
When I used it last, I ended up wrapping it in Castle ActiveRecord I got that frustrated with it.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
I wonder if my hatred for nHibernate and alike are not too exaggerated. I avoid using them at all times and have always preferred writing my own persistence layers. I had some bad experiences with these kind of tools and hate to loose control of how things are done. I know this comes at the cost of overall productivity, but in the end I believe it saves me time when I don't need to create super duper workarounds because the framework does something I didn't tell it to do. Or worse, as has happened on a project I worked. The lead architect decided to use LINQtoSQL and the entities generated were complex rendering the system unusable for performance reasons. Despite all tuning efforts, it was not enough and if it wasn't for the ORM, tuning the data layer would be much easier and feasible and we wouldn't need to rewrite the whole data layer using classic ADO.NET implementation. And I still have to mention that maintaining ORM based data layer can be either beautiful or hell with ORM. The problem is that with ORM, sometimes it's difficult to predict when you going to shoot yourself on the foot. What's your opinion about this? Is it worth the frustrations you're very likely to face? What about the risks of having a completely failed data layer? I've taken as a personal philosophy to never use ORMs on "real" projects, unless explicitly asked by the client or for demonstration purposes. I still have to give Entity Framework a try though.
-
I am looking for a job right now, so I looked over few offers, and i was surprised how many companies require employees to know that technology. And my question is why? I have read something about that now and before and I don't know what nHibernate have that don't have native for .net SQLinq? Is it better? Or this is because nHibernate work with Java to?
In soviet Russia code debugs You!
modified on Tuesday, April 5, 2011 12:55 PM
I usually don't use any kind of ORM framework, but now that EntityFramework 4 is out, I prefer to stick with that, since it's natively supported by the .net framework and is not so far behind nHibernate. nHibernate is still more mature than EntityFramework but I think the pro's of Entity are better than the cons.
-
My experience with it is somewhat mixed. One one side it can be a real pain to configure it and the crappy documentation does not make it any better. But once you got it working, it's really nice. Still, I prefer the oldfashioned way using stored procedures and setting up entities myself deep within the resource access layer. I just don't like it when some 'smart' framework tries to tell me what and what not to do.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011Me too, I hate the idea of loosing control.
-
Yeah and you can *always* tell an app that uses code generation and a framework like that because the UI is almost a mirror of the database completely throwing out the window all the modern principles of task oriented design. Those tools give you an app that looks like it was designed by an engineer not a designer.
There is no failure only feedback
John C wrote:
Yeah and you can *always* tell an app that uses code generation and a framework like that because the UI is almost a mirror of the database completely throwing out the window all the modern principles of task oriented design.
Incorrect/inappropriate use of a tool is not a condemenation of the tool but rather the user. However I would certainly love to see an analysis that demonstrates that most applications, large and small, do not show a strong correlation between tasks and data models. For example given small retailer I can't imagine that that when they want to order new inventory that they would not in fact be looking at an inventory 'table'.
John C wrote:
Those tools give you an app that looks like it was designed by an engineer not a designer.
Pretty sure that most developers are neither engineers nor designers. Although I have never actually seen a job description that said 'designer' which wasn't exclusively applied to a GUI programmer. And those positions were not architect positions.
-
John C wrote:
Yeah and you can *always* tell an app that uses code generation and a framework like that because the UI is almost a mirror of the database completely throwing out the window all the modern principles of task oriented design.
Incorrect/inappropriate use of a tool is not a condemenation of the tool but rather the user. However I would certainly love to see an analysis that demonstrates that most applications, large and small, do not show a strong correlation between tasks and data models. For example given small retailer I can't imagine that that when they want to order new inventory that they would not in fact be looking at an inventory 'table'.
John C wrote:
Those tools give you an app that looks like it was designed by an engineer not a designer.
Pretty sure that most developers are neither engineers nor designers. Although I have never actually seen a job description that said 'designer' which wasn't exclusively applied to a GUI programmer. And those positions were not architect positions.
jschell wrote:
Incorrect/inappropriate use of a tool is not a condemenation of the tool but rather the user.
It's an inappropriate tool for anything of consequence precisely because it leads people to poor design choices. It's single purpose is to save money, not to make great software. I expanded on why I think it's a poor tool for any job in depth in another reply, perhaps you missed it: http://www.codeproject.com/Lounge.aspx?msg=3847223#xx3847223xx[^]
jschell wrote:
However I would certainly love to see an analysis that demonstrates that most applications, large and small, do not show a strong correlation between tasks and data models.
You honestly think most applications are well designed and easy to use? :)
jschell wrote:
Pretty sure that most developers are neither engineers nor designers. Although I have never actually seen a job description that said 'designer' which wasn't exclusively applied to a GUI programmer. And those positions were not architect positions.
My terminology may be incorrect, what I mean is whatever people are calling a systems analyst and designer these days. I mean ultimately someone who is responsible for thinking like the customer and designing the interface (hence business object layer) accordingly.
There is no failure only feedback