Why nHibernate [modified]
-
Battle-tested? That's a good way to describe it. The problem is, that the developers have to wage one or another battle against it until they reach some staus quo. Doing everything myself would have been easier on my nerves than making this Diva happy. And its data caching gets a little heavy on the memory side when you have to fetch a greater amount of data. I don't really like to watch when a good server goes to its knees because it's running out of memory. Nope, I don't think this thing is worth the trouble.
"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 2011And I'd rather suffer death by a thousand toothpicks than write all the monotonous, tedious ADO.NET plumbing. :) To each his own.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango -
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 have found on occasion that when companies have a strict requirement for hiring based on a specific third party app, tool, library, etc, it may be because they recently lost their expert in it, and want to hire a direct replacement rather than have somebody new or in house take a peak and learn it.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
-
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
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.
-
And I'd rather suffer death by a thousand toothpicks than write all the monotonous, tedious ADO.NET plumbing. :) To each his own.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah HimangoSure. It would be very boring if we all would produce the same paint by numbers code :)
"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 -
AspDotNetDev wrote:
Know you can finally wrest in piece.
It looks like the US could use a few English teachers. ;P
"Real men drive manual transmission" - Rajesh.
-
NHibernate is perhaps the oldest and most battle-tested object-relational mapper (ORM) for .NET. If you don't know what ORMs are, or why they're useful, see here[^].
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah HimangoJudah 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!
-
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.