Jeff you took the words outta my mouth. Your idea gets a humble +1 from me.
I've no idea about IBATIS internals but I think Jeff is proposing
something which would greatly increase the usability of the mapping.
I' m working on a team project where the persistence layer is my baby and I hate exposing details of the persistence layer to the business layers.
For those who might see the problem I will briefly describe the shenanigens I have used to workaround it.
For DB-trash think PK values and some information that I need in order to be able how to sort out the mess when I read it back (for example a vector position index value when reading back a vector of domain objects so that the order is preserved).
<shenanigens>
I ended up writing PersistentX, PersistentY etc. where X and Y are the domain objects and the PersistentX looks like this:
public class PersistenX extends {
DBTrashValueClass dbTrash;
// loads of getters/setters() each delegating to dbTrash
long getPKCol1() { return dbTrash.getPKCol1(); }
long getPKCol2() { return dbTrash.getPKCol2(); }
int getOrderPosition() { return
dbTrash.getOrderPosition(); }
....
}
Before the persistence layer writes a domain object I have to instantiate a new "Persistent" object corresponding to the particular domain object, copy all attributes of the domain object to the "Persistent" version (I do this using Commons PropertyUtils), next I copy in all the DB persistence control information (). After all this I can pass the PersistentX as a parameter class for my INSERT.
</shenanigens>
This is a LOT of mucking around and is not a great example of object oriented programming.
I did consider using aspects to somehow introduce the db-trash into the domain objects rather than misusing inheritance for this task. For my present project this is a no-no (project manager wants a SIMPLE solution) but if the IBATIS framework did the aspect magic then I probably would have jumped at it. I think Hibernate does something similar using byte-code manipulation in some circumstances but I digress. I'm not a great fan of such tricks but they could be made optional.
Another enhancement that would probably make a huge difference would to be able to use OGNL expressions to access nested properties of the parameter class since often domain objects are nested.
Thanks,
Richard
- Proposed Enhancement - Support Multiple Parameter Classes Jeff Butler
- Re: Proposed Enhancement - Support Multiple Paramete... Larry Meadors
- Re: Proposed Enhancement - Support Multiple Para... Jeff Butler
- Re: Proposed Enhancement - Support Multiple ... Larry Meadors
- Re: Proposed Enhancement - Support Multiple Paramete... Brandon Goodin
- Re: Proposed Enhancement - Support Multiple Para... Jeff Butler
- Re: Proposed Enhancement - Support Multiple ... Brandon Goodin
- Re: Proposed Enhancement - Support Multi... Jeff Butler
- Re: Proposed Enhancement - Support Multiple Para... Richard Sullivan
- Re: Proposed Enhancement - Support Multiple Paramete... Richard Sullivan
- Re: Proposed Enhancement - Support Multiple Paramete... Clinton Begin