Hi,
Derek Broughton wrote:
Nathan Anderson wrote:
Okay, if the DB transactional safety can be ignored in this example. The
only way that comes to mind to make this work is to have your JE objects
have an option Transaction property. Then after you create the
Transaction instance you would set it on each of the JE's.
Does that work for your situation?
That's what I wanted to do, but I can't see how to create the parent record.
Look at it from a different direction. I have a object that has two
different parent objects - an Account and a Transaction. The only
relationship these two objects have is via the third object - so that
object has to be created before at least one of the parents. But my Action
knows how to create objects of its own type, not of others.
Like you guys, I've had lots of fun migrating my head from the
traditional DB-centric approach to solving problems like this. My
"copy-and-paste" fingers are on the game, but my head is still lagging :-)
That said, I believe I've previously got into problems with this kind of
issue by focusing too much on the model level. Not sure which archetype
you are using, but in the Basic Struts archetype I'm familiar with, I'd
be looking to empower a Manager class with the wherewithall to do the
job. I'd create a Manager class for your unnamed third object (UTO) and
give it access to the DAO(s) it needs to load/create/persist the UTOs
and return them to your Action. Your Action can then tell the Manager
to add/remove any dangly bits (Accounts and Transactions) it needs to
and finally persist it all to the Database. Theoretically, that way the
Manager takes care of all the DB transactional stuff for you.
HTH,
Rob Hills
Waikiki, Western Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
