I think you are both right on the button. When you need to manipulate
a series of objects and you want those changes to be in a single
transaction, then a Manager is your friend. At one point I found
that I kept writing Manager methods that are just reflections of my
DAO methods. I found in my actions, especially early on in a project,
were "small" in that they did a single save. So I reached some point
where I realized that I only really need a Manager if I need a longer
transaction that spans multiple saves. An example is when I am doing
audit trail/history saves.
There is something to be said for Managers being your "public api",
but I have really moved from a XFire WebServices model to a RESTful
data services model through my struts actions. So I would say that
DAOs are cool in your action for reads and "single saves". Higher
level constructs, beyond your average CRUD action, would probably
require a Manager. I think you start a project with a bunch of CRUD
and then you start refactoring or adding flows that make you think
about adding Managers. My advice would be to only add Managers when
they are needed.
With all that said, my personal preference is to try and avoid DAOs
referencing other DAOs. If the relationships are structural then they
can be handled with JPA annotations and through cascades they can be
saved on either side.
Seems like we will need to clarify the DAO/Manager concept, so users
don't feel constrained by a one to one pattern.
-D
On Mar 31, 2008, at 9:53 PM, Rob Hills wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
