Matt Raible wrote:
[... much removed ...]
I think Spring is great for assembling applications, but for something
like Roller that's practically "feature complete" - I don't know that
it makes a whole lot of sense. Then again, if Roller's backend is
difficult to test or maintain - using Spring would likely solve that.
I would say the decision to use Spring vs. don't use Spring should
like with the folks that work on Roller the most - which is you and
Dave. It sounds like neither of you are very enthusiastic about using
it - so my recommendation is simple. Don't. ;-)
Matt
I agree that Dave and Allen's consensus as well as understanding the
pattern will be critical. I'd like to think there are still major
components that the other committers have and will be contributing.
I admit it constitutes somewhat of a rearchitecture, and there should be
some feature-level drivers (like specific pluggable aspects in Roller).
What I have gained from it in the apps I've done recently is that the
resulting code is much more modifiable, modularized, pluggable, and I've
found that has helped me add enhancements and changes. The primary
beneficiary for Roller is the developer, meaning the committers and
especially the external non-committer enhancing/modifying Roller. The
indirect benefit to end-users comes when you have more developers adding
pluggable components for different bits of Roller functionality that
people can just pick up, plug in and use. That's a dream and not sure
if we will actually get there, but I think it is a good goal. Choosing
Spring definitely doesn't get us there on its own; the hard part is
still real architecture, but personally I've found that the dependency
injection pattern helps me stay in the right frame of mind to achieve
better modularity and more easily pluggable components.
--a.
