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.
Packt Publishing? (Score:1, Insightful)
Packt Publishing == $hill review == Slashvertisement.
Capitalism is greatest! (Score:2, Insightful)
Re:Packt Publishing? (Score:1, Insightful)
aren't pretty much all book reviews shashvertisements?
Re:Packt Publishing? (Score:1, Insightful)
Packt Publishing == $hill review == Slashvertisement.
Amen brother.
...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?
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.
- Matthew Parris
Re:Running Franticly (Score:3, Insightful)
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 (Score:3, Insightful)
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 (Score:1, Insightful)
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 (Score:4, Insightful)
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.
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 (Score:1, Insightful)
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 (Score:3, Insightful)
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 (Score:2, Insightful)
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.