• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate Annotations - Are they intrusive?

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Mark
 
Srikanth Shreenivas
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agreed that both will work. However, XML option seems less invasive and wont create unnecessary dependency for POJO on hibernate classes.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Mark
 
Srikanth Shreenivas
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
And then the entire population worshiped me like unto a god. Well, me and this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic