Anil Gangolli wrote:
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.


Yes, but that that is DI and it is important since the wiring of the backend is the primary way to extending Roller's core functionality.



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.


I'm not understanding what you mean here. You say it's misguided and then say it "makes sense" for the use case we are implementing here.



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.


I think you are going to have to provide more info about what you mean by the "cleanliness, pluggability, and replaceability" we will get from your notion of DI.

As I said in my response to Denis' Spring work, I think that DI is an important pattern and we should be using it more than we do now, but I do not think it's the pattern for everything and IMO Spring (and most Spring advocates) tend to over emphasize DI.



+1 but with hesitation and another plea to consider Spring.


Spring was always considered, it's just that a number of us who spent a reasonable amount of time doing the comparison preferred Guice.

-- Allen



--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


Reply via email to