Sound OO design principles dictate the use of interface/implementation pairs for java objects.

If, for example, I have IParent and IChild interfaces, and Parent/Child implementations respectively, how do I map these?

I don't seem to be able to map the IParent/IChild interfaces, and work directly with Parent/Child objects. I can map the concrete Parent/Child objects fine, but then the getter/setters cause problems if they deal with Interfaces. For example:


causes a exception during initialization.

I have searched the User Document, FAQs and forums with no luck. Is there a way of doing this that I am overlooking?

Any help would be appreciated.
-Mitch

P.S. I am using JDK 1.4.2 with Hibernate 2.1.

In my attempt at simplifying the situation may have introduced errors/confusion (sorry). I guess my best bet is to be explicit. Rather than Parent/Child, I actually have the following:


with a <one-to-one/> relationship between the two concrete objects. However, the references (i.e. getters/setters) each reference the Interface types, rather than concrete types.

My mappings look similar to this:

Any ideas why I'm getting the exception?

-Mitch

Actually, this is a point of much contention. I don't personally believe that creating extra useless artefacts is at all "sound". Are you really ever going to have two different implentations of your ICustomer interface?? IUser? How often have you ever seen that in practice? YAGNI applies.




It is trivial. Hibernate does not at all care that the property is declared of type IParent. If it actually always refers to a Parent, then map it that way.

<many-to-one name="parent" class="Parent"/>

done.

Thank you. Adding the class attribute did the trick.

As for the Interface/Implementation issue, it may complicate the issue a bit, but I'm developing an Eclipse RCP based application, and in order to avoid extensive/circular dependacies between plugins, I place Interface definitions in a 'core' plugin, required by all (plugins). Now I have a Hibernate 'persistance engine' plugin that provides concrete instances of those interfaces. With this model I can later replace the Hibernate persistance engine plugin with an EJB-CMP/XML/JDBC/What-have-you based persistence engine without modification to any other 'client' plugins.

Thanks again for your help.

Another reason for interfaces is that you might be making classes persistent when you don't know the actual concrete type. I've been working in this space, and I've found it's do-able (so far) with only a few minor extensions to Hibernate.

First off - why you would want to do this. In my particular case I'm working to have a single class that is both Hibernate and JAXB aware. I've created an XSD that contains JAXB annotations such that Hibernate XDoclet is generated when the JAXB interfaces are created and use those annotations to create the *.hbm.xml files. At runtime, the JAXB class is unspecified but meets the interface that Hibernate knows about.

The tricky part is getting Hibernate to (a) create the right class, and (b) recognize this class as being mapped. The first part I've accomplished by supplying an Interceptor that overrides instantiate() to call the JAXB object factory rather than directly calling the object. The second part required some small changes to the SessionFactory code, to introduce the actual mapped classes rather that the named interfaces.

As I've said - I'm pretty new to Hibernate (<1 wk) so I haven't gotten everything working yet. I'm working on associatiations now, for example - and am running into a slight wall that JAXB requires the List interface where Hibernate wants to use a Set. I'm going to look at the <bag> support and see if that gets me anywhere.

A related question, though - would the changes that I've made to SessionFactory be considered for inclusion in the Hibernate base? I think this style of programming (interface hierarchy mapped to class hierarchy) is interesting enough to be supported natively.