Hi all
Allen Gilliland wrote:
>Using Spring DI has been discussed on
> this list numerous times in the past and it has always ended the same
> way, without any actual code, so I'm sorry to say it but unless one of
> the Spring fans steps up to the plate and offers some real code then
> there is really only one option to vote for.
This sounds like I a challenge I'm ready to take up since I've just
started something like this :-)
I am working on a Spring demo of 3.1 with I hope not too much XML
headaches. I'm pretty happy with the results at the moment with the few
changes I've made and can forsee a few nice things that can now be done
easily (such as using interceptors on strategic places, transaction
management or EJB-fication). I'm also in the hope that it'll allow to
fill some of the requirements about the "easy installation" proposal
regarding property management and JNDI based resources.
I'll try to knock up something that is runnable based on the 3.1 branch.
It may take a little while to finish off (a few days probably), but
here's the overall idea:
-- Regroup the RollerImpl / HibernateRollerImpl managers in RollerImpl
for injection of the managers. Only the strategy in the
HibernateRollerImpl remains, which also allows for injecting the
hibernate session later.
-- RollerFactory is as usual the main entry point in Roller and is the
one responsible for getting the RollerImpl Spring bean (which replaces
instanciating RollerImpl in the getInstance() method).
-- Roller property files are loaded from Spring property loaders and
populate the datasource, hibernate config and other things with the
loaded values. Those properties can be overriden in various ways.
-- XXXManager(s) are declared as Spring beans. This makes the managers
implementations swappable at will. This is particularly nice when
experimenting with various Hibernate implementations and introduce
another DAO layer. It also allows to add a transaction manager around
some specific areas, and easily set interceptors in places.
-- Inject the Mail Session and Data source in a way that it can
decoupled from the web container and allow other configurable options
such as JNDI lookup, plain JDBC datasource, built-in mail session, etc.
The hard part in this is to actually de-wire the RollerConfig property
values used in the various manager implementations with something that
comes from the Spring configured..configuration. The rest should be
quite a breeze as the interfaces around layers are well defined.
Any comment or suggestions are much welcomed.
Cheers
Denis Balazuc
Allen Gilliland wrote:
It doesn't surprise me that there are more voices advocating Spring
simply because it's a more prevalent technology and more people are
familiar with it. I don't have any really strong opinions in the Spring
vs. Guice debate, I think that both can fit the need just fine. I have
tried to be a fan of Spring but like Dave I just haven't felt any real
appeal from the times I've worked with it. I don't think it's
particularly hard, it's just never really felt 'right' to me, and I'm
sorry but those xml config files really suck. I understand that they
are powerful, but IMO they are a PITA to read and deal with.
I also want to echo the subtle comment which Dave made about seeing a
prototype of a Roller backend wired via Spring. The fact is that it's
easy to prefer Spring over Guice in a discussion, but until someone puts
up some code to actually provide a functional Spring backend then this
discussion is somewhat academic. Using Spring DI has been discussed on
this list numerous times in the past and it has always ended the same
way, without any actual code, so I'm sorry to say it but unless one of
the Spring fans steps up to the plate and offers some real code then
there is really only one option to vote for.
-- Allen
