cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 00:01:39 GMT
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Hmm.  What we have here is a bad design.  Should the
> > container make up for your poor design?  Can you really get
> > away with only three instances in a pool with a web
> > environment?  Honestly, there is nothing in Cocoon that does
> > what you are talking about.
> 
> Yes, it is bad design. It is more than that - it is horrible design.
> 
> But admit one thing: It was not difficult to see that it was
> utterly atrocious!
> 
> I meant to use it to show a situation that may occur in a system. It
> will
> not be as clearly awful as the abomination I showed you, but *hidden*
> in the code. I can show you more poor architecture:
> 
>   public void tailRecursive (int i) {
>     if (i < 100) {
>       mycomp = lookup (...);
>       tailRecursive (i + 1);
>     }
>   }
> 
> Of course, the component should be passed in to the method. The point
is
> that you may have these patterns in your system on a much larger scale
> *without knowing* it.

I do not (fully) agree with you here.

In J2EE, it is common to have session EJBs working with JDBC connection.
You obtain connection whenever you need it and return to the pool when
you are done.

If you to write Avalon application after this pattern, you will have
several ThreadSafe components (session EJB) and one or more pools of
JDBC connections. Every component's responsibility will be to lookup and
return connection.

What you are proposing is to pass this connection across all these
components, and move the responsibility of connection management from
component which uses it to the caller who might not be aware about it at
all - and it should not, because caller does not need to know
component's dependencies.

Moreover, if component needs more then one component to work (and this
is not the rare case), or different components need different
connections/other components, you will end up with lots of arguments in
every business interface (or Map filled with required components... why
not just pass manager as an argument?)


> You will suddenly experience massive slowdowns and not know what is
> happening. After a few hours or days of going through code you realize
> that
> a certain method is being called multiple times. And that method does
a
> lookup.
> 
> > You have something more than "I may want to implement this
> > poor design some day" that we can discuss?
> 
> As I said above, I tried to show you a pattern by distilling it
> to a very short example. Apparently I failed so badly that you
> thought I really advocated writing of such code.
> 
> > Why not discourage bad design?
> 
> Why not? Well, it depends on how that discouragement is done.
> If designing your component poorly leads to YourCodeSucksErrors being
> thrown all over the place (with correct line number and file info) the
> moment you start the server, then I'm all for it.
> 
> But if, when you do something that is completely correct within the
> context of your component, but, in interaction with other parts of the
> system that you may not know of, leads to sporadic and erratic
behaviour
> seemingly unrelated to your code - then that discouragement is not
> helping anyone.

I completely agree with this point. This will make it very difficult to
write reusable components, and impossible to envision behavior of
complex system.

Vadim


> > Now, a way to philisophically enforce the "do" vs.
> > "represent" concept is to call the components by a new name:
> > services.  A service is a type of component that "does"
> > something or performs a service.
> 
> OK, got it.
> 
> I disagree, but that is for another time.
> 
> /LS



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message