When I was reading "Hibernate in Action", I liked the idea that when using Hibernate, POJOs need not implement any hibernate specific interface. The meta data describing mapping of POJO attributes and database columns are maintained outside code in .XML files.
With the introduction of Hibernate Annotations, in Hibernate 3.2 onwards, its now possible to express the mapping metadata using Annotations. This means that POJOs are now Hibernate aware with annotations being all around in the code.
Is this good or bad? It certainly makes POJOs dependent on ORM technology being used.
The whole purpose of Annotations introduction in Java 5 was to make expression of metadata simpler. However, will they always have side effects of making code dependent on certain technology?
Well, you do need to have the jar files in the classpath in order for them to compile, but after that you can use your objects as just POJOs and ignore the Hibernate stuff. Or continue to use xml mapping. They both work.
Re-read the first part of my reply above. I don't feel intrusive at all, I can use my POJO classes without considering Hibernate. I don't feel tightly coupled to Hibernate. And I find it much easier and cleaner to use Annotations, especially since you only have to add Annotations for the Exceptional cases where the defaults aren't what you want.
Joined: Jan 19, 2006
I been thinking about it and I think XML based meta data are the right choice for deployment time configuration data. Usage of XML in such scenarios allows easy re-configuration without the need for recompilation of code. Annotations are as good (or as bad) as programmatic configuration, and hence one should be cautious while opting for Annotations based meta data, and avoid their usage for representing information related to deploy time configuration.
On a different note, I was also thinking that what is the use of POJO when its not really collaborating with a framework like Hiberate or JSF/Struts. Its just an object with no or little behaviour attached to it. The real intelligence lies in the business objects or framework who persist them into database or construct a pretty GUI for them.
If frameworks do not force developer to implement a specific interface in order for an object to be used in framework, this is a good feature. However, dependency on framework will anyways get introduced the moment you decide to use a framework. Such dependency is not an issue when you are using a J2EE standards based technology such as JSP/Servlet or EJB.
For instance, If EJB3 proves to be equally viable option in comparison to Hibernate, one should pick the standard(ized) option which in this case is EJB3. Only in sceanrios where your requirements are such that you can not use any of the "current" J2EE spec based technology, and you decide to pick one of the open-source or third party frameworks, you are opening up your system to create dependency. Hence, It may not be realistic in such situations to have a goal to be framework-independent, or to be able to easily migrate from one vendor to another.
By selecting a framework which is relatively less intrusive, you can reduce the cost of potential migration in future.