Originally posted by Matt Gaunt:
Does your book cover users of hibernate at all levels. I would consider myself a more advanced user than someone just starting out.
My book really takes the user from the most fundamental part of using Hibernate, (which would be the basic downloading and installation of the JDK, a database, a
JDBC driver, and of course, the Hibernate core and Hibernate annotations module), to what I believe are fairly advanced topics, which would include using Hibernate in a web based application, and leveraging the DAO and other design
patterns such as the ServiceLocator, Factory and Singleton design patterns in order to create a very flexible and adaptable application design.
But one thing about the way I write, is that it's always very conversational. Even when I tackle advanced topics, it's written in a very informal and casual way. This, I believe, takes the edge off learning difficult topics, and makes understanding Hibernate and the use of
Java Persistence API Annotations
alot easier.
So, the book is for people wanting to learn Hibernate quickly, and it slowly progresses to more and more advanced topics. Having said that, the book never tries to pretend that it is a reference tome like Data Persistence with Hibernate. Hibernate Made Easy is designed to make learning the fundamentals of Hibernate fun, and it will get developers proficient at using Hibernate.
Originally posted by Matt Gaunt:
Further to this, one of the issues I have had in the work place is trying to convince others hibernate is a good tool to use. Many discussions about the loss of executing direct SQL when required and overriding hibernate standard select queries abound. It is very frustrating...
"We like your ideas, but they are new, so they scare us." That's always the type of thinking we're up against when we introduce new technologies, although, in the grand scheme of things, I'm not sure if we can still call Hibernate 3.2.6 'new.'
As you know, Hibernate doesn't take away the ability to perform direct database queries, as you can issue 'native queries.' Futhermore, any Java program that leverages hibernate can still leverage all of the libraries of the various jdbc packages, so Hibernate in now way ties your hands with regards to direct SQL and JDBC queries.
The size of your project, and the side of your company is always a factor, but for the most part, the biggest cost of any application is not the up front costs, or hardware, or anything like that, but instead, is the cost of long term maintenance, and finding people that can indeed maintain an application that has been developed. With Hibernate, your maintenance people really only need a good foudnation in Java, as Hibernate takes care of most of the persistence plumbing, so, future maintenance means finding Java programmers. On the other hand, an application that ties SQL directly into an application not only has serious flexibility problems, but also creates a situation where anyone doing future maintenance not only needs strong Java skills, but also needs strong database and query skills as well. That's always an important point to make.
Kindest regards!
-Cameron McKenzie