At 03:25 8/2/01, Rodney Waldhoff wrote:
>>This will of course entail a lot of work and will
>>actually also increase duplicity. Each bean will duplicate functionality
>>present in frameworks because it can not rely on the framework. Hence you
>>have not stopped duplication - you just
>>changed it from per-framework to per-component.
>
>I disagree. There are a number of clearly identifiable *services* that can
>easily be made fully, atomically self-contained. The framework for a
>connection pool, or a cache server, or a logging utility, or a regular
>expression parser, or lots of other things is that thing itself.
1. A regex parser - agreed,
2. A logging utility - partially agree
3. A cache server/connection pool - don't agree
I don't see 3 as working because they can/should be built on generic
pooling caching classes. The current Avalon connection pool inherits from
AbstractThreadSafePool (or something similar). Now to make that pool
independent of Avalon would require duplicating the code in the Pool
framework.
This is not uncommon - if you look around you will see even more pervasive
generic pooling/caching framework (minerva is a good example). Now by
forcing each component to be self contained then you force duplication of
code.
>>However things like DB pools that work best when integrated into a
>>framework will unlikely to see a lot of reuse (except the copy-paste kind)
>>if the framework is not adopted.
>
>I don't get it. Integration of the connection pool with another is simply a
>matter of having/invoking a "borrow connection" and a "return connection"
>method. Moreover, the JDK already has such factory interfaces--two in fact,
>DataSource and Driver. It's simply a matter of abstracting away the way in
>which the connection is obtained from the way in which it is used.
Well have a look at turbines pool. It carries other data like what type of
database it is associated with (and thus which subset of SQL to use). Look
at other connection pools - some will carry transaction data,
user/principle associations, data markers ... etc These *could* be done on
top of a connection pool but would require excessive amounts of work - so
much so that rewriting them from scratch or copy-paste coding is easier.
>Does it take more work to build and maintain these services in a modular
>fashion? Well, it takes a *little* more work up front,
I think you underestimate how much work it is. I have been working on a
generic framework who's charter is just that - and I have found it painful
to do. Worse it takes a lot of time.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
