Hi again, Derek - the fact that you have an object that has two "parents" is just another way of saying you have a many to many relationship. Every JE has exactly one Account and one Transaction, so it is the "join table" of your many to many relationship. As for the action only being able to create one type of object that is the exact reason Matt was hesitant to make AppGen or AMP for code generation. There is no reason you have to have a 1-to-1 ratio of persisted objects to DAO's, or even a 1-to-1 ratio of DAO's to Managers. Your action can talk to as many Managers as it needs. Your Managers can talk to as many DAO's (or other Managers) as it needs. Your DAO's can talk to as many DAO's as it needs, and can persist whatever objects are always required.
In this example, you never have a Transaction without any Journal Entries, and you never have a Journal Entry without a transaction. But, you can have an account without JE's or Transactions. So, if I were building this, I would have an AccountDao, and a TransactionDao. The AccountDao does exactly what you expect, in fact you could build it just like the PersonDao in the tutorial or generate it with AMP (although you will probably have to extend the GenericDao at some point, so you might as well from the beginning). The TransactionDao should persist both Transaction and JournalEntry objects, and it will probably need some convenience methods to help keep the objects linked properly, especially if the mapping between the objects is bi-directional (but that is a bit off-topic). I think you can get the point... Rob - While I would have tackled this problem at the DAO, it could have been done with Managers just as you suggested. My preference for the DAO in this case is because it is that the definition of these particular objects states one cannot exist without the other. If it were a different example I might have done the work in a Managers as well. Enjoy :) Nathan ----- "Rob Hills" <[EMAIL PROTECTED]> wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
