NHibernate 3.0 Cookbook

RickJWagner writes "Are you a .Net developer? Do you have to persist your application objects to a database? If so, I know of a book you might be interested in, Packt Publishing's NHibernate 3.0 Cookbook. NHibernate is a port of the popular Hibernate object-relational mapper (ORM, for those who like TLAs.) An object-relational mapper is a framework that lets the developer get and retrieve application state from a database, and it does so in an efficient, non-intrusive, and flexible manner. Hibernate is the top of the line ORM implementation, yet it's easy enough to learn that even a newbie will find it easy to get started." Read on for the rest of Rick's review. NHibernate 3.0 Cookbook author Dentler Jason pages 328 publisher Packt Publishing rating 7/10 reviewer RickJWagner ISBN 184951304X summary The ultimate "how-to" reference for NHibernate 3.0 This book is written in Packt's 'Cookbook' style, which means it's really a series of how-to templates that guide the reader through some goal-centric activity. A 'recipe' is a formula for accomplishing something, like setting up a session for a web application, or using a profiler with NHibernate, or creating a validator class. You may not know what some of these things do-- but you will when you read the recipe! Each recipe follows a repeated pattern, with sub-sections "Getting Ready", "How to do it", "How it works", "There's More". At first glance, this can be a little deceptive for readers of technical books-- there's really no lengthy text sections that explain the basics of the tool in the early chapters of the book. You might be lulled into thinking this means there's no explanation for how things work, but that would be wrong! The truth is, there is plenty of good NHibernate theory and explanation, it's just that it's contained within the "How it Works" and "There's More" section of each instructional section, not in a chapter devoted to overview just by itself. For this reason, I'd urge bookshelf browsers to be sure to read one topic through front-to-back thoroughly, to get a feel for how the book presents theory as well as practical hands-on-the-keyboard instruction.

As far as content goes, there is a lot of useful content in this book. The author presents 70 different recipes for activites that range from the basic (i.e. your first class-to-database mappings) to the unusual (i.e. using NHibernate Spatial for solving distance-related problems.) The author offers plenty of good text in most of these, but again-- don't be upset by the placement of the high-level material. It's all there, it's just placed a little differently than what you'd find in most technical books.

The book is easy to read. The text is plain and straight to the point, and the author's writing style is quite readable. The code examples are likewise clean and well-formatted. (By the way, I'd urge you to go to Packt's site to get the source bundle if you buy the book. There's a lot of code referenced, you certainly wouldn't want to type it all by hand if you can get it handed to you.) The book runs a little over 300 pages, and most of the type is generously spaced. This is not a strong theoretical reference, but it is more than adequate as a primer for the vast majority of the tasks you'd want to accomplish with NHibernate.

So who is this book good for? I'd give it high marks for .Net developers who want to use NHibernate, regardless of experience level with the tool. I say that because there are enough use cases presented that there is almost certainly a subset of new material for almost anyone. How about Java Hibernate users? I think it's a decent book for them-- NHibernate is a very close port of the base product, so a Java user can get something out of this book, too. (For that crowd, this would obviously not be a good primary choice, but is worthwhile reading if you already have a Java go-to reference for Hibernate.) For anyone else wanting a good high-level overview of ORM use-- I'd say this book is only of marginal value. This is because the bulk of the explanatory material is presented in the context of 'how to' accomplish some particular task and isn't easily accessible without skipping from recipe to recipe.

By the way, lest you think NHibernate is only for .Net devs, I mostly ran the code samples under MonoDevelop on Ubuntu. This was my first adventure with MonoDevelop (the open source IDE for Mono, which itself is an open source, multi-platform port of .Net.) I was pleasantly surprised by the level of polish in the development environment, it really is a nice environment. Again, if you're a Java developer, I'd consider this book a decent learning supplement but would not recommend it as a primary for Hibernate proper.

You can purchase NHibernate 3.0 Cookbook from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Packt Publishing?

[Anonymous Coward]

Packt Publishing == $hill review == Slashvertisement.

Re:Packt Publishing?

[Anonymous Coward]

aren't pretty much all book reviews shashvertisements?

Re:Packt Publishing?

[Anonymous Coward]

Packt Publishing == $hill review == Slashvertisement.

Amen brother.

There's one great way you can tell a shill that you think he does a great job, that you approve of deceptive advertising and would love to see more of it, that you support astroturfing, and that lying to customers by telling them that a biased advertisement is really an unbiased book review is perfectly acceptable. If you want to do all of the above, you can buy whatever products they're hawking.

This quote about TV is true because of two forces: advertising and PR. If you want it to be more and more true about the Internet, just keep buying from shills and companies known to employ them.

Television lies. All television lies. It lies persistently, instinctively and by habit. Everyone involved lies. A culture of mendacity surrounds the medium, and those who work there live it, breath it and prosper by it. I know of no area of public life -- no, not even politics -- more saturated by a professional cynicism. If you want a word that takes you to the core of it, I would offer rigged.

...is it dishonest for the presenter to imply that the pundit in the chair is free to offer any opinion, when the truth is that fifty pundits were telephoned, but only the fellow prepared to offer the requisite opinion was invited?

- Matthew Parris

Re:Packt Publishing?

[Anonymous Coward]

There does seem to be some sort of a relationship between Rick Wagner and Packt, as he's reviewed, blogged and commented on reviews of several of their products. There ought to be some sort of a disclaimer on this posting.

Re:Packt Publishing?

[K. S. Kyosuke]

He probably has some sort of packt with them.

Re:Packt Publishing?

[Anonymous Coward]

That joke... smells like the shit your boyfriend packt.

Re:Packt Publishing?

[RickJWagner]

Thanks for reading my stuff. Especially the blog, please do visit that one often. (I use AdSense, if you visit my blog about a million times I'll make a dollar or so.) ;) But do please note: I review tech books from other publishers, too. A few examples: http://www.javalobby.org/articles/jboss-seam-rick/ (Apress) http://www.javalobby.org/articles/beautiful-code/ (O Reilly) http://rickwagner.blogspot.com/2010/11/book-review-spring-dynamic-modules-in.html (Manning) Full disclosure: I always sign my real name to my reviews, I have never received payment of any kind from anyone, except for sometimes a copy of the book to be reviewed. My reviews tend to be honest but maybe a little on the kind side, as sometimes books appeal to some people but not all. I try to be as technically accurate as possible. Watch for future reviews: Erlang and OTP in Action (Manning) JBoss AS 5 Performance Tuning (Packt) Please do keep reading my reviews! Thanks, Rick

Another Convincing Slashvertisement $$$ Ka-Ching!

[Anonymous Coward]

Shit like this is why I have no compunctions about fully blocking all banner ads on Slashdot at all times, since long before they had that "disable advertising" checkbox.

P.S. does Slashdot ever have a book review where the reviewer really does not like the book and straight-up recommends that we should not buy it? You'd expect to see those on occasion in a non-advertising non-product-placement honest unbiased list of reviews. Strangely enough they're unheard-of on Slashdot. Why, it's almost as though they're really just ads.

Fuck astroturfing, fuck shills, and fuck deceptive advertising. And especially fuck those great enablers, the useful idiot assholes who defend it and pretend like it's legitimate.

If you like the ActiveRecord pattern

[osgeek]

Take a look at the Castle Project, which implements Active Record on top of nHibernate.

It's very nicely done.

Re:If you like the ActiveRecord pattern

[Mongoose Disciple]

I'm still holding a grudge against them for Monorail.

Let's throw away the useful parts of ASP.NET while still keeping its overhead, in order to make writing the kinds of web apps that already aren't very hard faster and the kinds of web apps that are interesting impossible to create! And while we're at it, let's put most of the useful documentation in videos instead of something sensible.

Disclaimer: I worked with it circa '07 and it may not be as rage-inducing now.

Capitalism is greatest!

[h00manist]

In Soviet Russia, we had gross government propaganda. Now, in Free Capitalist America, we have access to much better, and more refined marketing techniques. And it's all you can eat!

Running Franticly

[GWBasic]

I had the misfortune of developing with NHibernate. The root of the problem was that the engineers who started the project didn't know anything about database programming and just used NHibernate as a magic persistance layer. (These guys would write foreach loops that would suck most of the database into RAM.) Ultimately, as I learned the tool, I found that it just makes data access more complicated then it needs to be. In order to use it right, you have to know the underlying database programming concepts, which are simpler and easier to learn then the NHibernate library.

To make matters worse, when I used NHibernate, there was a bug in runtime code generation, which was very hard to track down and impossible to fix.

My opinion: Stick with a simple ADO -> Object mapper and write queries as-needed. If you use NHibernate, stick with the basic CRUD features. Don't rely on a more complicated library to handle things like transactions, lazy-loading, and relationship mapping. Be very careful introducing relationships into the business objects, especially automatically-populated ones. And, whatever you do, if you end up working in a project where the senior engineers and/or people who started the project treat NHibernate as a "magic persistance layer," RUN!!!

Oh, and if you work on a project that wants a "magic persistance layer," because the engineers don't get databases, investigate document databases like MongoDB, Couch, ect. The document model maps a lot better to the object-oriented way of doing things, thus it's a lot harder for programmers who don't get databases to screw them up.

Re:Running Franticly

[Anonymous Coward]

I totally agree with parent. Actually you can call NHibernate anything, but for god's sake don't call it "efficient". It is as if programmed by a bunch of placement students. No seriously. No comments, exceptions being swallowed, the works. I agree that perhaps Hibernate was a great evolution in bridging the OO/DB paradigms, but NHibernate (the .NET port) isn't. There are easier and more documented ways to deal with persistence in .NET, such as Linq to SQL.

Re:Running Franticly

[danparker276]

Yep, agree. SQL queries work and are easy to debug.

Re:Running Franticly

[__aamnbm3774]

I was going to reply to the parent because we don't use NHibernate, but we do use Linq to SQL.

Since the majority of my database calls are Select statements, LINQ to SQL has made my code a lot cleaner. Include things like improved readability, intellisense, and the flexibility to change my database tables around while just updating a graph, has been a god-send.

Granted, I've been in the IT-world for a while and I have seen what happens when you let the computer automate 'too much' for you. So I can feel the parents pain. But at the moment, I get a heck of a lot more done in a lot less time than I used to when I was writing SQL queries by hand and then passing the results to a DataReader.

Re:Running Franticly

[fusiongyro]

I agree completely. I'm glad you wrote this. I wish more people would take this advice to heart.

My situation at work is identical, except with Java and regular Hibernate. My predecessors used Hibernate figuring they could ignore the database. I came in long afterwards. I've spent the last month trying to improve the situation with Hibernate, but there's only so much that can be done when your codebase assumes that all your objects are always in memory.

Without wanting to distract too much from what comes closer to total agreement than anything I've ever experienced on Slashdot, I am, personally, rather against "document" databases. While there wouldn't have been a Hibernate mapping to screw up or relational theory to misunderstand, I think my team would have ultimately just fetched everything from it and stuffed it back in like we're doing now. Perhaps that wouldn't be as big of a mistake with CouchDB. It would be hard to determine now.

Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.

Re:Running Franticly

[mattpalmer1086]

Well, I'm currently working on a project that uses Hibernate in Java, and it's really quite hideous. I speak as someone who designed an object-relational mapping system ten years ago. Hibernate is much more powerful than anything I ever hoped to do - and it still sucks. We're talking about an application with 2 core classes, with a one-to-many relationship. Three tables in the underlying database. So it's about as simple a data model as you can get.

To get it to perform, we're having to manually add indexes to the database instead of relying on hibernates automatic index generation. We're having to specify access patterns in queries and annotations. We have queries with sub-selects, which hibernate just doesn't do well. We have the need to return dynamically generated values along with the objects, which is not obvious with Hibernate, but easy in SQL. We have a mixture of HQL (Hibernate Query Language), JP-QL (Java Persistence Query Language), annotations in the code to specify mappings, and some XML mapping configuration.

It's all so bl**dy complicated, it's not obvious what works well and what doesn't, and what to do about it if it doesn't work well. So we're fighting this thing all the way, and increasingly dropping back down to SQL, which is mature and well understood.

The thing I've learned about Java development and developers is they are in love with interfaces, abstraction and frameworks. And its very nice to have standard ways of doing things, and pluggable interfaces, and modularity, and all that goodness.

In many ways, this code has all the standardisation and modularity that I've been pushing as good things for years. But I guess you can have too much of a good thing. Sometimes, it really is better just to write a simpler thing yourself, instead of wrestling with ridiculously powerful APIs which are trying to satisfy everyone, and yet somehow end up never quite doing the "obvious" thing you happen to want to do.

Re:Running Franticly

[scorp1us]

I am using NHibernate for the first time.

I wrote a layer like this by myself about 10 years ago for PHP. I gave up on it because I found it shallow and pedantic. If you have a developer that can't write a SQL query, then you need to look at your hiring practices or get some training. A basic technology like SQL is now 38 years old. It's not a secret.

What's more the HQL is so similar to SQL as to not make a damn bit of difference. So what do you get? POCO mappings. The object management is handy, but really how often do you do that? And when you do, how complicated is it really? If you need anything more than a hash table for field mappings, you're doing it wrong. And waht's more POCO mappings are not automatic. You need to write more C# code, And you have to document your database in a second language (XML format) violating DRY principals... So overall you write more code because someone didn't learn to use a tool (SQL) properly. Not a win.

Re:Running Franticly

[WarwickRyan]

What the ORM gives you (in addition to the obvious) is the power to make large scale changes to your persistance infrastructure quickly and easily.

Take caching as an example. Every time you touch the database, you pay a relatively high cost. If the data you're accessing doesn't have complex sorting or querying, then you can dramatically improve performance by caching in the webserver's memory. If your db is on the network, then the cost is even higher. Guess what? With an ORM such as nHibernate, you can have this data cached, with just a runtime setting. No downtime. No code changes.

For projects of a certain size (not tiny, but not google/facebook size) the ability to be able to tweak your data access via configuration is well worth the initial 'extra' cost of using an ORM.

As you say though, there are too many poor developers out there who don't understand their tools. However, you can't disparage a whole technology just because a certain group of users are too stupid to be able to use it right. It's actually a good thing: inept developers / architects / 'engineers' are flagged early on when they treat an ORM as "magic persistance layer". Much better than hiding in the woodwork until it's too late get rid of them.

Re:Running Franticly

[Tablizer]

The root of the problem was that the engineers who started the project didn't know anything about database programming and just used NHibernate as a magic persistance layer.

There is a growing consensus in the industry that OOP is not well-suited at direct modeling of domain (business) objects, such as employees, products, invoices, etc. I believe this is partly because OOP lacks inherent collection-oriented idioms, and would otherwise reinvent the database if it did. Further, heavy collection-orientation tends to violate "pure" encapsulation, creating a philosophical conflict.

OOP has worked relatively well for GUI's, presentation, and OS/system calls and services though. But with these one is dealing with dozens of instances, not thousands, which may be a clue about the difference in effectiveness.

OOP has it's place, but that place is not everywhere. Multi-paradigm programming is catching on, and it generally agrees with this observation: use the best paradigm/tool for the job; and none is best for all jobs.

Re:Running Franticly

[Anonymous Coward]

You can't assume that one abstraction means you can ignore all others. If you use NHibernate you should already know about database programming and basic ADO. You don't get a free pass on the subjects when working with relational databases. Assuming NHibernate is going to be a golden ticket that means you get to ignore all ideas around a RDBMS is ridiculous. I have found that personally using NHibernate greatly reduces the amount of code I have to write and maintain and reduces the complexity of that code (including configuration) at the cost of having to KNOW NHibernate ON TOP OF relational databases and SQL. ADO.NET and a few patterns you should be at least aware of. On smaller projects I just roll my own DAL, but on larger more complicated domain models I find NHibernate excellent, which is probably what it is targeting.

To say that if you don't understand RDBMSs then you can just run to a DocDB, is absurd. You should be figuring out how your application works best then figure out the best way to do persistence and reporting. Why fight your database or get involved with a sophisticated ORM if you don't have to. In my case, it's usually mandated to use a RDBMS. So I find NHibernate very useful at times.

Re:Running Franticly

[randallman]

My experience has been similar to yours. I agree with you about the issues that exist, though I don't agree with your prescription to use only the basic features. ORM can drastically reduce code complexity and still perform well if you are willing to properly learn how to use the library and understand performance trade-offs. The main problem is that most people aren't willing to put in the time and effort (as with most everything in life).

Some tips.

• Make sure you have a good database design to begin with.
• Turn on logging so that you can see the SQL statements issued. Are you pulling every field from a table when all you need is one? Are you selecting from related tables that aren't needed. Not everything need be done is the most efficient manner, but consider where optimizations can and should be performed.
• Automated tests. Test your data model to make sure it performs both properly and efficiently.

When using ORM, you have do have to pay attention to what's happening underneath. It's a trade-off, but in the end your code is much more simple and portable. After spending time with an ORM, surprise, you learn how to use it better.

Re:Running Franticly

[Anonymous Coward]

I have been scratching my head at the heavy use of Hibernate and Castor in various projects and could not, for the life of me, figure out what benefit they brought to the development of a product over using ADO.NET directly. It seems to me that Hibernate and Castor are a side-effect of the kind of people who work in the software industry nowadays: people who really only know one or two technologies and are either unwilling or unable to learn new things; i.e. lousy engineers. For example, I've had to work with developers who could not and would not learn to write C programs, which is necessary in many system integrations since C is often the lingua franca of glue code. [These developers (who earned in excess of $120,000/year also claimed to only know Java and could neither learn nor write programs in *any* other language.]

Your comment has confirmed my suspicions -- to the clueful, Hibernate is very likely just a waste of time. I certain have no desire to learn Hibernate's own query language.

Re:Running Franticly

[Anonymous Coward]

This is a classic case of a workman blaming his tools. Often, beginners start using NHibernate without fully understanding how it works and how to manage it (for example, if you're wrapping NHibernate around a repository pattern, you're doing it wrong and *will* eventually get burnt). And you're right, you do need to know the underlying database programming concepts; thinking you can ignore this even with the most powerful ORM is wishful thinking.

Make sure you use the right tool/patterns - NHibernate Profiler, IOC, and session and Unit of Work management. Pick the right querying language best suited to your needs, and mix and match them all in the same project (SQL, HQL, Linq, Criteria, QueryOver etc.)

And programmers who don't get databases shouldn't even think of touching NHibernate. It's an incredibly powerful tool, and if you use it wrong, expect the worst. :)

Re:Running Franticly

[mugnyte]

  Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?

  As someone who's written an ORM that handled a medium swatch of the features for the product space (metadata, state, caching, lazy-loading, transactions mgmt, SQL generation, etc). I can say that done well, ORMs greatly simplify database-backed systems for any system size over ~10 tables, or systems with less-than-solid feature requirements.

  Simply put, there is a finite set of operations one can do against an RDBMS, and if you can continue doing all of them, then the tool shouldn't matter. Hand-scribing up your own SQL and linking it to code any way you like is fine, if you like maintaining a huge pile of boring and building estimates by the number of impacted queries from a feature request.

You have to know the tool well - it doesn't make data flow management easier, it just moves the switches and dials to a single layer. For the vast majority of cases, ORMs are amazingly helpful.

  NHibernate and it's similars serve a legit purpose, and are used successfully throughout the dev world.

  Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract and other modern terms for not-so-modern concepts, Object-Relational Mapping is just another tool. And like all tools - there's a world of detail under a seemingly simple concept.

 

Re:Running Franticly

[ZFox]

Have you looked at FluentNHibernate? It does away with the xml mapping files and strongly types everything (although it does this using lambda expressions, so expect a .net 3.5 requirement).

I've been pleased with it and have been able to perform some pretty complex mappings to legacy databases with it (but you have the option to fall back to hml if things get real complex).

Re:Running Franticly

[Anonymous Coward]

Gosh. I use NHibernate extensively. Sounds like you just had incompetent people writing code.

I've seen people use ADO record sets to select entire tables, only to loop over them, instead of using a WHERE statement.

Bad programmers are everywhere.

What NH lets me do is make my code more well documented and testable. I get compile time support for modifying fields and such. That's useful. Same reason you use any abstraction layer.

I still break out into SQL when needed, as you should. It's a tool. Discover it's uses and take advantage of the benefits.

Re:Running Franticly

[GWBasic]

Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?

Both.

The problem was rooted in the fact that the engineers who started and lead the project had no clue how to program with a relational database, and treated NHibernate as a magic persistance layer. They would just quote the mantra of "Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract" and then totally misunderstand how to act on the concepts.

IE, they would do things like foreach over an entire table instead of "select where parentid=123". They would also suck an entire database into RAM, change 1-2 fields, instead of writing a simple update statement. When it was appropriate to just write a %$@%#$ query, they would write tons of C# that would put a huge load on the database. They would also do things like load tons of objects and pass them around, when all you need are IDs.

So yes, it was a mis-applied tool. But, the issue was complicated that those of us who knew how to use a database just found that NHibernate would get in our way when 100s of lines of C# would be better replaced by a simple stored procedure. IE, NHibernate never added any value, except for simplifying basic CRUD.

In contrast, the most successful database work that I've done had a database programming expert on the team. The vast majority of data manipulation was done in raw SQL with stored procedures, and then we had a simple ORM that helped populate query results and generate wrappers to call stored procedures. There wasn't any framework to get in the way.

Re:Running Franticly

[mrtom852]

It seems that more people are starting to realize the problems you've mentioned. I have always been amazed that practically every feature I could ever want is in Hibernate but at the end of the day knowledge that would have been gained about the underlying database is just replaced with Hibernate trivia.

The two things that always amaze across projects is how little people understand hibernate's Session (sometimes not at all!) and how people fall in to the trap of creating huge object graphs. Developers often don't see passed the mapping and querying concepts despite it only being half the story.

Re:Running Franticly

[Bill Dog]

But isn't using an ORM still mean SQL in your C# code, and then what about shops that like stored procedures for the SQL because they're compiled and the code doesn't need to be sent to the DBMS each time for executing?

Re:Running Franticly

[mugnyte]

  We were discussing this just today in the office. ORMs can suffer from huge impedance issues if not used correctly: Too chatty/lazy/narrow or too wide/wasteful.

  Overall, they're trying to pick a middle ground between writing plumbing per-UI need and having a one-size-fits-none model inflator. There's a lot of tricks in there (caching, lazy loading, dynamic objects, etc) but overall it's the same trade-off any system faces.

  There shouldn't be mountains of C# to wade through to get data. If so, the implementation is off. The concept, however, I a big fan of. Even when the impedance is high.

Re:Running Franticly

[Skal Tura]

Sounds to me like you are describing the average coder in general, not just on this instance they were idiots :D

Also, can basic CRUD be made much simpler than it is, it's BASIC crud afterall :)

The most successfull DB work i've done was where 2/3 of the team were highly skilled DB admins. We did multiple very heavy data driven web applications, and got the insanely high amounts of data being handled really fast, but we did not use ANY stored procedures. Simply not seeing the value of a stored procedure making things more complicated (logic in DB, no thanks. Ever).

Tho, another project, we had customer complaining it was too slow and they hired a 3rd party "veteran DB administrator & optimizer" to help us. I spent like 20hrs compiling data to him, so that he could in the end say "Well, apart from adding this single index, i have no clue how to make it faster" to which i got to reply "That index does not help, we tried it and it was slower than using these indexes in every single test we threw at it". I did gather some knowledge on tracing performance characteristics from him tho.

I wonder "why it was slow", due to client initiated changes in hardware, we had only 2xDual quad xeons with 16Gb ram each to use for whole system, including frontend. So another server handled 100% DB, and another 20%/80% DB/Frontend, and our data set had few billion rows of highly relative complex data, including tons and tons of free form textual data to be searched. If i recall right DB + Indexes were around 20-24Gb in just our 1/8th sized testing data set.
And the result why it was slow? Insane demands, not actual code, but the specifications required more than was practicable. We spent probably 150hrs optimizing, just to fall short 5% from the goal, when we could've simply added a single 4k eur node to increase capacity by almost 150% (Nehalem architecture was released).

Re:Running Franticly

[__aamnbm3774]

No, I rarely write SQL queries in code anymore. Occasionally there might be something I can't do in Linq to SQL, but you aren't losing functionality, you're adding another layer.

You could call stored procedures the old fashioned way if it was appropriate to do so.

Being able to create objects from tables without writing tons of wrapper code is awesome, it's unfortunate NHibernate isn't getting better reviews.

Re:Running Franticly

[eennaarbrak]

My predecessors used Hibernate figuring they could ignore the database

And there is the problem. Hibernate's designers never claimed that you could ignore the database. In fact, one of the biggest strengths of Hibernate is the fact that it does not hide the database away from you - an area where some other ORM tools (like JDO) falls flat.

... there's only so much that can be done when your codebase assumes that all your objects are always in memory

Hibernate does not promote this view of persistence at all. It has a clearly defined object lifecycle and state model which allows specific control over how your entities interact with the database. Seems like you are blaming Hibernate for the shortcomings of your (or your predecessor's) design.

Hibernate, and ORM in general, gives other advantages. Like being able to do second level caching and clustering with minimal configuration. It also reduces the amount of JDBC (or SQL) code for the most mundane (but also most significant) situations like CRUD, and using a clever combination of lazy-loading and fetching strategies allows you to optimally interact with your database without writing complex lifecycle management code. It makes your application more maintainable by providing a centralized configuration, meaning that you have less work to do when your database schema changes.

And to preempt, yes, these advantages does have a cost. Hibernate's lifecycle and state model does not suit everybody's view of how ORM is supposed to work. The trick is to understand, in your specific situation, whether the cost is off-set by the benefit or not.

Re:Running Franticly

[cromar]

Almost everything you say seems to be a misunderstanding of the best features of NHibernate.

These guys would write foreach loops that would suck most of the database into RAM.

NHibernate provides modular caching, so this is what you want. Generally, the data in the database is used by the application, so the more that is in memory the better.

I found that it just makes data access more complicated

It is perhaps the only library that allows true OO for database driven apps in .NET You may think it is "more complicated" than the ad-hoc data widgets provided by Microsoft, but those are tools ill fitted for any serious application. The benefits of a well defined object model are not to be sniffed at.

To make matters worse, when I used NHibernate, there was a bug in runtime code generation, which was very hard to track down and impossible to fix.

I sort of doubt this. Can you provide a ticket number for this bug?

Stick with a simple ADO -> Object mapper and write queries as-needed.

Perhaps if you are writing one-off homepages and photo albums and can't be bothered to learn how to write decent programs (or maybe you are a VB programmer anyway).

Don't rely on a more complicated library to handle things like transactions

As the author of several 10,000 to 100,000 user web applications, I can tell you that NHibernate's transactions and the lock construct from C# are amazing. Furthermore lazy loading and relationship mapping work great in NHibernate... It is very easy to specify when you want a relationship to be lazily loaded and when not, a simple attribute value needs to change.

Be very careful introducing relationships into the business objects, especially automatically-populated ones

(This is what lazy loading is for and it is very easy to set it on or off.)

As a final thought, I would ask why to use NOSQL databases with C# when you can use NHibernate and memcached to persist objects without a need for another data layer? There are plenty of valid reasons either way. And I'm sorry to take the piss out of you, but you don't know what you are talking about.

Re:Running Franticly

[Anonymous Coward]

What the hell is with ORMs?, most of them suck, introduce too much overhead or both, after trying many of the Python based ORMs that was it, why can we have some of that in other languages? SQLAlchemy very powerful and can get down to low level queries doing SQL and act as a simple connection manager if needed, or Django ORM it gets the job done, correctly and very easily, even other "lesser" Python ORMs like Storm or SQLObject are piece of cake to work with, get it to work and get it to do what you need, in comparison with stuff like NHibernate, Entity, Castle ActiveRecord, Subsonic, etc.

Re:Running Franticly

[Anonymous Coward]

Finally some that knows what they are talking about.... Nice to know that at least there is one person that is talking sensible instead of just posting uninformed opinions about something they obviously know nothing about.

Re:Running Franticly

[TempestRose]

I must agree with the parent. nHibernate has allowed me to save countless hours writing CRUD.
Using FluentnHibernate helped even more.
Was there a learning curve for both of these? You bet your ass there was.
Was it worth it? hell yes. I use nHibernate in every project I can.
Was the learning curve shorter than just writing all the crud? I don't think so. But no one should expect miracles from their first nHibernate implementation.
You'll see some benefits, but the big benefits will probably come in on your third implementation.

Probably just like the way it works when you learn other new technologies. Amazing, isn't it?

Also, I saw a comment up above about efficiency. Unless you write all your SQL as

select server.db.table.column1, server.db.table.column2, (etc) from server.db (etc etc fully qualifying everything )

nHibernate is MORE efficient and faster than you and your stored procs are. ( Not to say that SPs should never be used. As usual, every tech has its appropriate place .)

Sure, you can be anal and write sql that way, but who actually does that consistently?

Just my opinion that nHibernate is definitely worth it, and not as bad as others have indicated.

Re:Running Franticly

[Anonymous Coward]

You could call stored procedures the old fashioned way if it was appropriate to do so.

You can call a SPROC in Entity Framework or L2Sql. They appear as a method call, the sproc params being the method parameters. This can be done in NHibernate as well.

Re:Running Franticly

[Civil_Disobedient]

I can't believe this screed got a +5 Informative. Your argument makes no sense.

The root of the problem was that the engineers who started the project didn't know anything about database programming and just used NHibernate as a magic persistance layer.

Really? They didn't know anything about database programming? First off: what does database programming have to do with .NET/Java programming? Second: how does someone who doesn't know anything about database programming go about creating libraries that do database access? I'm serious: how do you do that? That's like accusing Toyota of being full of engineers that don't know how to build a car just because the ride is bumpy.

In order to use it right, you have to know the underlying database programming concepts, which are simpler and easier to learn then the NHibernate library.

You keep using this term: "database programming." What in the hell are you talking about? Are you talking about stored procedures? Are you talking about writing relational database software? Are you talking about the software written by third party developers that uses the libraries?

Or are you just talking about SQL? I think that's it. I think you're using the term "database programming" to mean "SQL statements" which explains a SHIT TON.

My opinion: Stick with a simple ADO -> Object mapper and write queries as-needed

Yeah, named parameters are overrated, too. Just concatenate a big string together. And if you need to check user input, just write your own parsing library because I'm sure it will be better than an open source, freely available version worked on by thousands of contributors. Nothing could possibly go wrong there.

Don't rely on a more complicated library to handle things like transactions, lazy-loading, and relationship mapping.

Sigh.

1. Hibernate doesn't handle transaction management.
2. Reinventing the wheel is reason #1 for getting fucked-up, hard-to-find bugs in your code.

Be very careful introducing relationships into the business objects

Says the programmer. "What the hell are you talking about? You don't touch business objects," replies the DBA.

if you end up working in a project where the senior engineers and/or people who started the project treat NHibernate as a "magic persistance layer," RUN!!!

OK, here you're absolutely right! Please run away! There are plenty of good programmers that can use a job. Let the scared hand-query-writers go whip up a website for their local bands and restaurants.

Re:Running Franticly

[GWBasic]

Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.

Be careful with DB4o. I played with in in 2005-2006, and its object-loading scheme was somewhat confusing. You need to "know" that your in-memory objects can be incomplete, which means that you continually need to activate them.

MongoDB, with their C# drivers, is a very similar "sales pitch" to Objectivity. Both the MongoDB and Objectivity drivers let you work with real C# objects. The reason why I like MongoDB, (in addition to its cost,) is that you can have an entire graph of objects that are persisted to the database as a document, and then you can query the database to get back these objects.

Frankly, the reason why I recommend "document" databases instead of object oriented ones is that, in situations like MongoDB, they pretty much are an object-oriented database, except the "document" aspect means that you don't get into the incomplete object graph issue that db4o put me in.

Re:Running Franticly

[GWBasic]

There shouldn't be mountains of C# to wade through to get data. If so, the implementation is off. The concept, however, I a big fan of. Even when the impedance is high.

Which gets down to the root problem: The developers wrote a mountain of useless C#. ORM really wasn't an appropriate tool for the project, because it just didn't need all of the things that you use ORM for. All that was needed was a simple layer to map ADO results to objects, or even better, a document database.

Good summary

[Anonymous Coward]

You see how he defined his acronyms, and what NHibernate was for? Thats how you do a good summary. You only hear people bitching when the summary is bad. Good summaries never get praise around here.

This thing is completely irrelevant to my interests, but thank you very much Rick for your summary. It probably saved a lot of people time.

LOL

[PJ6]

and it does so in an efficient, non-intrusive, and flexible manner

Bwahahahaha!!!

Persist what?

[Anonymous Coward]

"Persist" is not a transitive verb.

whatever happend to that reviewed-anything guy?

[Anonymous Coward]

Member the guy who reviewed anything and everything and always got trounced by the readers here? To where did he slither off? Sledge? Or Sludge?

Re:whatever happend to that reviewed-anything guy?

[Anonymous Coward]

George Castanza is who you're think of.

LINQ to SQL

[Anonymous Coward]

LINQ to SQL is much better than nHibernate.

If any one of the "Free" (as in Java) Software evangelists tries to convince you that their tools on par with .NET, just show them LINQ to SQL and watch their arrogance turn in to amazement.

Re:LINQ to SQL

[prionic6]

I'm no evangelist... I'll bite anyway. LINQ for SQL seem to be basically a query builder pattern with syntactic sugar. I'd say most of it could be emulated in Java by some annotation processing and intelligently chosen constants. It looks nice, but I'm not _that_ impressed, sorry.

Re:LINQ to SQL

[Galestar]

To be honest, LINQ to SQL was never that good to begin with, and its also deprecated.

Re:LINQ to SQL

[Richard_at_work]

Not it isn't deprecated, that rumours been going around for a while but its still under active development at Microsoft - .Net 4.0 included some fairly hefty updates to Linq to SQL. There is no evidence of it being dropped any time soon.

Re:Hilarious!

[Anonymous Coward]

Yeah, having to ask that question is pretty hilarious. You can be pretty certain that any relevant developer today knows C#.

Timesaver

[Anonymous Coward]

I use Nhibernate daily at work and the time it saves for projects is significant. SQL Select statements are easy to write yes, but for projects with CRUD statements for 50 tables with up to 80 columns in each I will take as much help as I can get.

Re:Hilarious! -- Yes, you are

[Anonymous Coward]

Yeah, all programs for the CLR are written in C#, all programs for Windows are written in managed code, all the world (including the iPhone) runs Windows or has a working CLR implementation ...

Re:Hilarious!

[Anonymous Coward]

Whereas outside of your windows-application world you got there, hardly anyone knows C#. ... Mostly because 90% of what it was good for is going web-services. Bye~

OR mappers all suck

[rubies]

They do. I've been struggling with commercial and free ones since C++ was the hottest environment around and they all basically do the same thing: spit out useless code that is impossible to optimise on a large database. You can't tune it reliably, you end up with indexes out the kazoo all over your database trying to catch all the special cases that the damn OR mapper makes up and they all have truly, ugly, broken interfaces to anything a normal database programmer uses like stored procedures.

I wrote one myself for the last project I worked on and, yep, it sucked just as hard as the commercial offerings for all the same reason.

They are, however, infinitely superior to object databases which truly are the spawn of the devil.

Re:OR mappers all suck

[Skal Tura]

I have pretty much the same experience about ORMs, tho my experience is far more limited.

But i somehow doubt it was just coincidence that the worst coder i've seen in my life is also the only coder i've seen using any ORM :)

My belief is that ORM is for newbs who cannot comprehend the data structures/query language, or both. Resulting in doubly evil end results. But yeah, it seems to be that for the most part it's insanely hard for people to make simple efficient code with sane abstraction levels, and not abstractions for the sake of abstraction.

Did it include "Just say no"?

[Uzik2]

NHibernate's implementation might be fine for Java but sucks for Desktop applications. Instead of paying the cost of parsing the object mapping files once (when the web server is started) you pay for it every time you start your application. It also guarantees that your efficiency is awful because of the way it's designed. Do yourself a favor and use something else.

Don't Buy

[Anonymous Coward]

I have this book, it is trash. It sort of assumes that you are already very familiar with NHibernate, and some of the 'recipes' are just plain wrong / poorly explained. For example, they never mention that to use FluentNHibernate for configuration in Nhibernate 3.0, you have to go find and build the source yourself. Not a big deal, but should certainly be part of the 'recipe'. This is just the first oversight of many that come to mind.

Re:Another Convincing Slashvertisement $$$ Ka-Chin

[bsDaemon]

Also, what's the ratio of non-packt publishing to packt publishing books? This publisher seems to have come out of nowhere, push out a ton of second-rate crap, then try and stealth market via this sort of thing. I haven't really found anything buy them that's even been worth pirating, honestly.

ORM efficient

[Skal Tura]

ORM is anything but efficient.

Also, my experience of ORM so far it is for Newbs who cannot comprehend the data structures by themselves, making it doubly inefficient.

Well, maybe one day i'll see a good example where it actually is efficient and powerfull :)

Re:ORM efficient

[Civil_Disobedient]

my experience of ORM so far it is for Newbs who cannot comprehend the data structures by themselves

It's obvious you don't know what you're talking about. Data structures have nothing to do with ORM.

Entity Framework

[Anonymous Coward]

Folks do know that Microsoft started including Entity Framework in .Net, and that there are connectors that support it for MySql, MsSql, and PostGre right? Why would you add another dependency to a project when the .Net runtime already provides this?

Re:Entity Framework

[TechBCEternity]

NHibernate has been around since 2005, Entity Framework is the MS copy of it that's appeared the last couple years, its quite xml heavy last I checked

Use Entity Framework

[Anonymous Coward]

If you are a .NET developer and want to use an ORM, use ADO.NET's Entity Framework.

For those dismissing ORM's...Domain Modeling is where things are going. Its not fine to just stick with the old Active Record way of doing things unless you want to get left behind. It has nothing to do with n00bs not being able to understand data structures...

Re:Another Convincing Slashvertisement $$$ Ka-Chin

[Anonymous Coward]

>This publisher seems to have come out of nowhere

Not quite - when Wrox folded (the big red books with programmers on the covers are now actually published by Wiley) and the royalties and fees owed to many authors and staff were written off, the guy who owned it went a few hundred yards down the road (back to the office where Wrox originally started) and founded Packt, presumably with money siphoned out of Wrox before the end.

Their business model seems to be to get contributors to open source projects to write for them for below market rates with the promise that their projects will benefit from the exposure of a book.

It seems like every other Slashdot book review is for a Packt book nowerdays. I suspect "RickJWagner" is on the Packt staff. If not, then he has an unhealthy obsession with them as they seem to be the only books he reads.

May I suggest something better...

[Anonymous Coward]

I live with the pain of using Hibernate (Java version) every day. May I suggest something sane instead: use SimpleORM!

Read this white paper: http://www.simpleorm.org/sorm/whitepaper.html

Even if you don't end up using it the whitepaper will give you some good insights into why not to use Hibernate

Thank god!

[Civil_Disobedient]

Thank god for all the bitching scripting "programmers" that despise ORMs and would rather use hand-written SQL statements. You keep the rest of us happily, steadily employed.

Re:Hilarious!

[Anonymous Coward]

Are you one of those idiots who think C/C++ make up 99% of the job market, and that Java and C# aren't used at all? You realize you can write web services with C#, right? I'm guessing the answer to those questions is yes and no, in that order.