I'm Newbie to Hibernate Persistance and Spring and I want to know from you the answer on my question in few sentences: what is important, when starting with Hibernate Persistence and Spring?
I'm familiar with Java SE, Java EE (EJB 2.1,JSF). From my project experience I know there are technologies outside with problems, f. e. EJB 2.1. (Code Generators, Deployment Descriptors, Stateful Beans, Session Beans), also f. e. JSF (Dynamically Loading, Application Beans, Session Beans, Request Beans, Page Beans). Actually I start to work with AspectJ. I think, I go in the direction of Spring: now, what is important, avoiding mistakes when going in a start-up, using these technologies? Or, eventually, is Spring free from failures, faults and errors? Will Hibernate Persistence defends me from mistakes, too?
what is important, when starting with Hibernate Persistence and Spring?
Well, I would say from my experience is - whether Hibernate is required for a project and why? I have seen projects using hibernate where simple queries can do the job and more efficiently. Other things include the basics like caching and transaction management
now, what is important, avoiding mistakes when going in a start-up, using these technologies? Or, eventually, is Spring free from failures, faults and errors? Will Hibernate Persistence defends me from mistakes, too?
There is always room for mistakes. Nothing is fool-proof. The important point is the decision to learn these technologies and try it out in a non-critical project. If they work for you and you are able to see the benefit replicate them in other areas. I would say there are tons of issues and workarounds in Hibernate and Spring - but it all depends on requirements whether you discover or touch those areas.
Programmers and programming techniques result in failures, faults and errors. The APIs are written in most generic form, as simple as possible and yet most reusable.
If it is a small application (or if it is already deployed application) which needs CRUD operations on not-perfectly-designed Database then I would say JDBC should work pretty good alternative and Hibernate here is a overhead and there would be performance bottleneck. And also by using frameworks like Hibernate you'll forget SQL.
You may use Spring and Hibernate frameworks if you're not comfortable with EJB, yes there were many pitfalls with EJB especially with Entity Beans till EJB2 but now EJB3 is more powerful with Annotations & JPA in place. Spring has advantage of connecting different components with thin wire but heavy XML configurations. Hibernate has its own advantages of caching , transactions, pagination etc.
As with anything, you need to know what each technology provides for you. Spring and Hibernate "do a lot for you". This means it is imperitive that you take baby steps in your implementation.
1) Learn what EntityManager is and does. Learn how Spring can configure, inject and manage this for you.
2) Make sure your database will not require a lot of complex joins. As with any persistence mechansim, fetches are expensive. If an object has many associations that need to be hydrated at runtime, it can begin to bog down performance.
3) Create a very small example, and I cannot stress this enough, take one step at a time to build up your code.
4) For Hibernate, dont worry about caching up front; however, you will want to know more about it as your get later in your project. Hibernate can be a performance hog for a variety of reasons, usually because of improper fetching strategies, unnecessary mappings and poorly written hql.
5) You need to decide if you will leverage hydrated entities throughout the layers of your application. There are pros and cons to this, such as state management and freshness of your objects. Seam can be a consideration; though, it adds more complexity to your overall solution.