Why nHibernate [modified]
-
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
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 2011 -
Nope, I found more. That's why the joke icon. It was supposed to be funny, ya know? Looks like a bad joke though. :~
"Real men drive manual transmission" - Rajesh.
Yeah, I got both senses, but I wasn't sure if you meant the more entertaining self-referential joke or not. :)
-
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
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 Himango -
"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
Ennis Ray Lynch, Jr. wrote:
code like Int32.Parse(someValue.ToString()) where some value is itself an int
Ha! That is easily explained. There is no overload of Int32.Parse() that takes an int, so you have to call ToString(), stupid! ;P
-
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 HimangoBattle-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 2011 -
n.podbielski wrote:
to now that
'know' Its a trickky one, a silent 'k'. As for the SW I have never heard of it though. :)
"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
my 'k' sticks sometimes too... ;)
Steve _________________ I C(++) therefore I am
-
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
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.
-
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
-
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)