Hello All
I have been reading with much interests the discussion about injection
and Roller.
I'm a fan of DI, inversion of control. I think this is a very good
direction to take for Roller.
As Anil though, I am wondering about the choice of Google Guice compared
to Spring.
Spring has now a good history of working well in production systems,
people are now used to it and it comes as a natural addition for
assembling java applications with various frameworks, including Struts2,
Hibernate and...Roller :-). A lot has been done and proven in Spring,
which I'm not sure has equivalents in Guice.
Also, regarding XML, there are many ways (through property files and
such) to avoid exposing end-users to Spring's XML without having to make
cookie-cutting design decisions. Spring would also fit well within the
"easier installation" improvement.
As previously pointed out too, unit testing and integration testing
setup (mocking objects, creating stubs to replace implementation
classes, etc.) can also be done very easily with Spring and usually with
the swap of an XML configuration. The same applies for business layers
which you may replace transparently. For instance, one can use an
EJB-based implementation of an interface (to benefit from
container-managed transactions, distribute some processing, using
message queues for notifications in place of e-mails, etc.) rather than
us a plain java one - doors are fully opened to the advanced user while
the complexity is totally hidden for the common users.
There are many ways to avoid problems such as multiple hibernate session
factories, default constructors where singletons are more welcomed and
other caveats, but usually it is more a matter of design choices within
the application than a choice of a DI API.
I am not familiar with Guice and not sure it can offer as much as Spring
does, with the maturity of Spring. I guess it's time for me to look into
it, but in the meantime If I could vote, I'd be in favor of choosing
Spring ;-)
My 2 cents
DB
Anil Gangolli wrote:
I'm really happy that we are playing in this direction, because I think
adopting the DI model, if we really adopt it fundamentally, will tend to
improve our modularity and clarify dependencies.
On the choice of Guice, I have concerns. From my perspective Spring is
more mature, well-documented and tested, has a more open contribution
model, and is in wider use amongst a broader community. Plus we have at
least two committers that are using it in other settings.
I understand some of the aversion to the XML configuration. Still XML
can be readily manipulated both manually and automatically during
installation; I hope we won't be asking users to modify distributed code
in order, for example, to add plugins or to swap a rendering model
implementation.
--a.
