> I'm crossposting this to xdoclet-devel... Ok, but wait! This is not so easy to solve as I first thought.
I attached examples:
- User.java (User Interface)
- UserImpl.java (User implementation that Hibernate should use)
What I'm after is that I should not have to know UserImpl in anywhere in
my code, expect when I'm creating a new User to db.
So my queries look like this:
public User get(Long identifier) {
if (identifier == null) throw new NullPointerException("Method
can only be invoked with proper Long object.");
User user = null;
Session ss = null;
Transaction tx = null;
try {
ss = session.get();
tx = ss.beginTransaction();
user = (User) ss.load(User.class, identifier);
} catch (HibernateException e) {
throw new NestableRuntimeException(e);
} finally {
if (tx != null) try { tx.rollback(); } catch
(HibernateException e) { }
try { session.close(); } catch (HibernateException e) { }
}
return user;
}
As you see, I use User.class to load object. That doesn't work, because
the mapping is written for UserImpl ('cause it's the only possibility).
Now I'm asking Gavin about why does Hibernate need concrete
implementation class? Hibernate already can generate proxy classes based
on interface, then would it be possible to provide this same support for
persistent classes altogether and make hibernate only to care about
interfaces (of course current concrete class support should also be
provided).
I have to think about this a little bit more. What others think?
> > Well, your request already arrived at the person in
> > charge. But would it be real advantage?
Not a big one, but it gives me nice possibility to separate
implementation and interface. Then I for example can write Action that
implements User. Then I have my action consistent with interface and can
use IDE features to automatically implement needed methods.
I might have several implementations lying around, then I can even pass
my Action class to UserManager to persist newly created user. No need to
copy any values to new UserImpl object and then persist it. It really
gives many choices that make it sound very nice!
> What shall we do with subclasses?
What do you mean?
Kind Regards
Aapo
UserType.java
Description: Binary data
User.java
Description: Binary data
UserImpl.java
Description: Binary data
