views:

334

answers:

2

I have a requirement to create a component which can be used stand-alone or within a larger application. When used stand-alone, it should not require a database, nor any database/ORM related dependencies. When used as as part of a larger app, some of the classes will indeed be persisted to a database via JPA/Hibernate.

I was thinking the domain objects in the component would not have any annotations (due to the requirement to not have any ORM-related dependencies). In the larger app, I would then sub-class those domain objects...which is about as far as I've made it.

Typically, I use field-level Annotations. Is it possible to due with with the scenario described above? I'm thinking it's not.

The other thought I had to switch to annotating the properties. In which case, I'd extends the non-annotated domain object, override all the properties, & annotate those. The child would just be a delegate with the required annotations. This just seem like a lot of work/code.

Ironically, I think this would be more easily doable if I was using hbm.xml, which we've recently moved away from. Am I missing something with annotations?

+3  A: 

The JPA annotations are really your only dependency. If somebody is using your object in a POJO (non DB) way that all they will need is the JPA annotations jar, which for a most application servers is actually on the classpath anyhow.

Surely just having the annotations as a dependency is pretty reasonable, it's no like you need to drag in the whole of hibernate and it's many friends.

The alternative is as you've worked out is to use hbm's for this entity. It's not that bad, as hibernate is quite happy mixing annotation and hbm style entities in a single SessionFactory and you can still use field access so don't need to compromise the public interface to your class.

Gareth Davis
Using the hbm.xml format is not a possibility because we are also using Enver for historical/audit tracking of our entities and it requires annotations (currently).I'm thinking pushing back and trying to get allowance for a minimal dependency is probably the best approach. I was just hoping I was overlooking some other easy/sensible solution.
Jamie Bisotti
A: 

If your requirement for no dependency is strict, then I suggest following it, avoid even the annotations dependency.

I would not subclass the domain objects just to annotate them. I believe this is more trouble than it helps.
Subclassing is easy on one entity, but on referenced entities it gets messy. You have to subclass all your entities, redo all constructors (because they are not inherited) etc.

For me, the xml configuration fits well in this case. Although some people (I do) prefer the annotations, the xml is still valid. It's fire-tested, well documented, well known, and readily available.

If you really don't want to write the xml, you can generate it using HibernateTools, ideally from your database (but other options are possible, the tool is versatile).

If the need for annotations is very strong, I would turn to code-generation. I would create normally my domain objects using annotations. I would then generate the non-annotated version of the class from that, just removing the annotations.

The classes would be different then .. this may impact the rest of your code. If they have the same full names (but only one is provided in a given configuration), you probably will compile your code against each version... If you need to use either without recompiling, you could also generate a common parent interface (without annotations)...

KLE