Anil Gangolli wrote:
I think using the dependency injection pattern would really help us
clean up interdependencies and make Roller more pluggable and
modifiable.
Right. The dependency injection pattern can be used to make Roller
pluggable and modifiable without adding a (direct) dependency on any
framework. If Spring were used for wiring up the objects, that would be
a dependency on Spring for initialization/configuration, but each
object/facade/subsystem would be free of dependencies on Spring and
could be reusable (and testable) without dependencies on Spring or the
rest of Roller.
Before spending time on a real proposal, I wanted to gauge
interest in this.
I'm interested, but I see your proposal as multiple proposals (or at
least involving multiple decisions): 1) Adopting IOS/Dependency
Injection as a default/preferred architectural strategy, and 2-n)
Whether/how to apply IOC/DI to solve one or more specific problems.
Given the (perceived) reluctance on the part of David and Allen to adopt
new frameworks/dependencies, it may be best to focus on some specific
problems or enhancements that IOC/Spring can help with. Although, one
could also argue that by adopting a preference for IOC may make the
individual decisions easier and result in greater consistency in the
project.
Note that this is separable from any inclination to
use Spring MVC (as Sean G is trying)
Agreed. Even the Spring developers view Spring MVC as a very separable
from using Spring in other parts of the project. In the case of the
Roller blog/feed presentation layer, Spring MVC brings value in view
independence and in URL handling, and I aim to present this convincingly
(as I find time) but they are clearly separate decisions. More later...
or other Spring features (like the
declarative transaction management that Matt R suggested).
If Spring were a "one trick pony", this would probably be the trick.
Pluggable O/R mapping is also part of the recipe. It seems to me that
this is an area where IOC/Spring could be helpful to Roller, especially
given Allen's proposal to do some refactoring in this area. This could
also be a good test case for IOC/Spring in general. If Allen is open to
considering declarative transaction management with Spring, and your
game, this would be a great way to start using IOC/Spring in the project.
Taking this path would suggest that we use Spring's xml-based
configuration mechanisms instead of roller.properties.
There are multiple strategies for migration/conversion, I would think.
One idea I've toyed around with (and used in a much simpler webapp) is
using Spring Beans to wrap configuration properties in such a way that
they could be loaded from either JNDI or from a properties file. This
allows for creation of an "immutable WAR file" that doesn't require any
local configuration info. It worked well for a relatively simple
webapp that was deployed on Tomcat (so we'd just put the config
information for each target server in a Tomcat context.xml file.) I
haven't tried this with more complicated apps or with Web Containers or
J2EE servers other than Tomcat, but this could help make Roller easier
to deploy and manage in multi-server environments.
Would there be sufficient support for seeing a proposal along these
lines? I probably won't embark on such a proposal unless there's some
predisposition to move in this direction.
I'm willing to help on this as much as I can, but I'm hoping to be
focused on implementing the separate, but related, Spring MVC proposal.
Regards,
Sean
