Dependency injection / inversion of control / service oriented
architectures are definitely the latest fashion in software
engineering -- and every fad wants to run amock. There's a tendency
-- especially in the Java world -- to take a situational principle
and turn into a global rule. It's a lot easier to think, "Always do
X!" than "Is X appropriate in this situation?" (The truth is that
there are even times when you really don't need getter and setter
methods. Shocking!)
But it's worth keeping in mind that, beneath the fad, there is a real
problem that dependency injection solves. Because Tapestry uses
Hivemind, it's possible to customize a lot of behaviors (e.g.
squeezing custom types to strings, custom URL schemes, custom
lifecycle hooks) without forking code or playing nastry tricks with
subclasses. Hivemind is well worth the 4 or 5 seconds Tapestry takes
to start up on my laptop.
I do agree, though, that use of dependency injection can get out of
control, and may not be necessary in every Tapestry project. So ask
yourself: "Is this a customization point? Do I need to decouple these
two classes?" If your team is small and self-contained enough that
tight coupling of code isn't a problem, if your project only gets
deployed for one customer and customization isn't an issue, if
decoupling makes the code harder to comprehend -- don't do it!
Conversely, if decoupling and non-intrusive customization are
problems for you, dependency injection may be a good solution.
Cheers,
Paul
On Aug 14, 2005, at 8:22 AM, Vjeran Marcinko wrote:
Hi all.
I started experimentally porting my small Tapestry3.0 apps to 4.0),
and cannot get away from feel that dependency injection is a bit
overkill for web pages/components. (BTW, boot time in 4.0 is much,
much larger. I assume it is due to HiveMind bytecode enhancing many
things in there ?)
Maybe it's because I always tend to unit test just business
classes, not web ones, so I don't see so much usefulness in DI
there. I don't run into cases when I want to inject different
implementations of dependency in my web page/component class. Are
there some other benefits?
Burden is that when using service locator, if some dependency is
needed on many places (such as Visit) I can centralize fetching of
this object in superclass, and on the other hand, with DI, I have
to define it in every spec XML. I know that annotations will come
to rescue, but untill then.... :-(
Similar case is page that requires many messages from .properties.
In old 3.0 days it's not much work, just call getMessage(key) and
that's it. Now, I would have to inject every message by specifying
it in XML. Too much typing just for simple message fetch. Same for
injecting pages..etc...
Suddenly, my page classes end up having really lot of ugly abstract
methods, and long spec XMLs...
Thoughts?
Cheers,
Vjeran
_________________________________________________________________
"Nationalism is an infantile disease. It is the measles of mankind."
-- Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
