When I read the fine print on the proposal it basically sounds like we aren't really much real adoption of DI at all, and we are just introducing the use of Guice to wire the manager layer up.
I still think the choice of Guice over Spring is misguided in our context. Annotation/code-based injection makes sense for the manager/persistence wire-up and other component bindings where non-committing developers are less likely to want to change things post-distribution, exactly where it's being used in this limited proposal. As it stands it's a small step in the DI direction and a more significant step towards adopting Guice rather than Spring for our DI basis, kind of the opposite of what I would have liked to see personally. If this is a way to get us comfortable with going further with DI, I'm all for it, because I want to see us go much further along that track. I'm more interested in the cleanliness, "pluggability" and "replaceability" we will get by adopting the DI model more fundamentally throughout Roller. +1 but with hesitation and another plea to consider Spring. --a. On Thu, 2007-06-21 at 09:31 -0400, Elias Torres wrote: > I have been playing with Guice and I'm starting to like it. > > +1 > > -Elias > > Dave wrote: > > Now that the EZ install/boostrapping work is complete in the trunk > > and I've brought the roller_guice branch in line with the new regime, > > I'm ready to start talking DI again. This is the last bit of work that > > I'd like to get in before the 4.0 release. > > > > Here's the start of the proposal: > > > > This proposal introduces DI in Roller in a pretty limited way. The > > idea is to get a DI framework into Roller so we can start rooting out > > our various factories and singletons, making the code easier to test, > > manage and providing more extension points. > > > > As it stands today it's only benefits are that it 1) allows a > > customizer to easily switch out Roller manager classes and replace > > them with their own implementations and 2) make it possible for > > RollerFactory to instantiate other Roller-dependent classes created by > > folks who are customizing Roller. > > > > These requirements are met by this proposal. > > > > * Introduce DI > > ** Use DI to setup the Roller instance and managers, i.e. manager > > classes should no longer be hard-coded into the Roller implementation > > class, instead they should be injected. > > ** Enforce singletons, i.e. singletons should have a private constructor. > > ** Use constructor injection to ensure that immutable objects remain > > immutable. > > > > * Do not change Roller API > > ** Do not change the was Roller back-end interfaces are accessed by > > front-end code > > ** i.e. RollerFactory.getRoller() stays in place > > > > * Do not change way Roller is configured > > ** Do not introduce any additional configuration files for those > > installing Roller, i.e. don't change the fact that the only > > customization file users should ever have to touch is > > roller-custom.properties. > > ** Do not introduce any additional configuration files for developers, > > i.e. developers should not have to deal with any new XML or property > > files. > > ** Maintain the same level of back-end pluggability, i.e. it should > > still be possible to switch back-end implementations by setting a > > single property in the Roller configuration file. > > > > > > Read the rest here, with > > http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Introduce+DI+with+Guice > > > > > > Comments? > > > > - Dave > >
