Hi Corey,
On Mon, 2002-10-14 at 22:59, Corey Jewett wrote:
> Several components I am writing have a unified access class that sublets
> it's actions to a set of providers. Example:
>
> AuthLogic might simultaneously have an HTTPProvider, SQLProvider, and
> LDAPProvider. AuthLogic is responsible for directing auth requests to
> the appropriate provider and returning a response.
>
> Ideally each provider would have a full component lifecycle. Currently
> AuthLogic is acting as a sort of pseudocontainer, wherein it provides a
> partial lifecycle (partial meaning a subset of it's own lifecycle).
> Preferable Merlin would be used to load/manage these providers.
>
> I know I can declare each provider and then tell AuthLogic which
> components to hunt down. I dislike this methodology as it seems clunky
> at best, confusing and hard to manage at worst.
It all depends on the particular situation, I guess, but we've found
this approach to generally work rather well =)
regardless...
> Would it be appropriate/possible to upgrade AuthLogic from a component
> to a custom container.
yes. Fortress in particular is built for extensibility and creating
custom containers (take a look at some of the fortress examples). I'm
not sure how easy it is to extend/customize/embed Merlin on a small
scale like this, but I am sure it is possible.
> I am considering this 'upgrade' for several components. What negative
> effects would such an action have on future development.
to me it sounds like "AuthLogic" is a business component. If you make it
a container, you also make it handle 'system-level' concerns, even if
most of those concerns are handled for you in parent or contained
classes. That might be awkward and it might increase maintainance cost.
It will usually increase memory footprint as well, though usually not so
much it matters.
However, in many systems a multiple-custom-container setup is the best
way to get the job done, and it can help you provide some logical
grouping/hierarchy.
Note that a possible negative is that laying 'low-level' connections
between your app and merlin or fortress will no doubt increase
maintainance time/cost as we're talking about alpha software and APIs
can be subject to change.
Finally, you should also consider how coarse-grained or fine-grained you
want your components to be. If your current providers look like:
Provider
{
parameterize()
initialize()
// business methods
dispose()
}
it might make sense to not make them components at all, instead using
regular interfaces/classes. This increase coupling and generally
somewhat reduces reusability of your providers, but you'll end up with
simpler drawings =)
hope this helps a little =)
- Leo Simons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
