skrev:
> ;-). I do not necessarily believe in code reuse, but
> definitely in
> design reuse. If I have to tweak my design into what
> is hot on the
> market today, I will have to redo it tomorrow when
> the brand new and
> much faster one pops up. If the component model fits
> your business
> model, rock on, but the main thing for me is to keep
> a clear interface.
What I don't agree here (and I think we may have
discussed this before irl) is the following: One needs
a component model/architecture/framework, especially
in design and implementation. The design is _always_
bound to that component model and have to be reworked
from analysis to change component model. There are two
things to do, either one uses a component model
out-of-the-box or one invents one for yourself.
I always prefer using things out-of-the-box because
that component model has been provided by people much
smarter spending much longer time designing, testing,
redesigning than I could ever do in my lifetime. Yet
even more unlikely within the scope of one project.
Also if you're using the component model in design
that your gonna use in implementation and deployment
you get a design optimized for that component model
and thus a better system in the end. (Like for
example, the remote/local design-issues.)
And remember, with J2EE one is bound to the component
model not a specific product. Which feels way more
safe than the COM+-alternative.
Inventing a new component model is for the gurus. For
me, it's a pleasure looking and using the results of
the people who designed J2EE and the architectures
adopted for it in the later days.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
