NHibernate 3.0 Cookbook 72
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.
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.| 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 |
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.
Running Franticly (Score:5, Informative)
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 (Score:3, Informative)
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 (Score:3, Informative)
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.