Hi Nathan,
Nathan Anderson wrote:
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...
You're quite right here of course, the entity relationships have to be
established correctly at the start or nothing will work properly. My
comment about focusing too much on the model level assumed that the
ER/model design had all been sorted out
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.
I'm sure there are many ways of doing this and I've been hunting around
for a while to find a good online resource that explains in words of 1-2
syllables and from a high-level perspective the "best" way to use the
Actions, Managers and DAOs we find in an AppFuse application. Some
clever people have put this structure together for good reasons I'm sure
and it would be good to read some kind of strategic overview of those
reasons. My main reason for suggesting the Manager level to perform the
kinds of things you guys are talking about is that I believe that
transactions are managed (behind the scenes) at the Manager level.
OTOH, I consider a DAO to be "atomic" and your explanation of your
reasons for choosing the DAO (the interrelationship between these
objects' states) also gels with me. That interrelationship could either
be handled in a Transactional context from the Manager, or directly from
the DAO. Which way is "right" or "best", I don't know. Maybe it
depends on whether the interrelationships between Account, Transaction
and JournalEntry are categorised as "Business" or "Structural". It'd be
good to hear some other opinions on that (with reasons).
Sorry if this seems to be sidetracking a little, but I believe that
sorting out design things like this early on can save a lot of work later.
Cheers,
Rob Hills
Waikiki, Western Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
