Hi all,
I have considered implementing the DAO pattern using Avalon for a long time
now, as this pattern provides some real benefits. You are right when you're
talking about a common interface which provides clients with
implementation-agnostic services such as findContract(contractId),
updateUser(user)... Multiple implementations could then be plugged. I have
myself used such an architecture where a common interface had two distinct
implementations, one used JDBC to access a DB, one used JCS to access a
mainframe. Both implementations did some mapping from the data repository
to a common object model. The clients just used the common interface and
object model, without even knowing they were talking with a DB or a
mainframe.
Now, as I'm investigating Merlin container, I think your idea sounds good
but looks like what I have done before. I would like a more dynamic
configuration using Merlin (or Fortress ?) capabilities. I mean, what about
having a DAOManager registered which would be capable of handling a
specific lifecycle extension, such as DAOCapable (or a base DAO interface
could be used as the extension). Every DAO implementation could declare
this extension, and be automaticlly registred with a given hint (or
whatever parameter could be useful) by the Manager at deployment time,
provided (I haven't given it a close look) there is a way to pass specific
parameters for a given component during lifecycle extension.
Laurent
J Aaron Farr
<[EMAIL PROTECTED] To: Avalon framework users
<[EMAIL PROTECTED]>
.com> cc:
Subject: Re: Avalon DAO component
02/25/2003 11:13
PM
Please respond to
"Avalon framework
users"
--- Robert McIntosh <[EMAIL PROTECTED]> wrote:
> >
> True, but you would have to have the ProductDao be a wrapper for
> whatever lies underneath, which is not necessarily a bad thing :-)
> Hey, you could even have multiple persistence layers at work, and each
> is a different 'service' that you access by name/hint. Would be a neat
> idea...
>
> - Robert
>
Yes, the ProductDAO would just be an interface. Think of the ProductDAO as
an
Avalon component's ROLE class. How you design your ROLE is dependant on
how
you need to use it.
Here's an example:
The DaoManager would have a configuration (file) that would give it a dao
context, a transaction class implemetation for that context, and a list of
dao's with their corresponding implementations (or something like that):
Then when you init the DaoManager, you tell it which context to use and it
will
give you the right Transaction object and the right DAO implementation
according to your configuration. It's very similiar idea to a
ServiceManager,
but it's simplified for just DAO's which means Transactions (Connections)
and
the objects that use them.
jaaron
PS- Gotta run for the next couple of hours, but if anyone has any thoughts,
I'd
love to discuss them. Thanks
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
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]
