Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

Brian,

We have an article on the Spring site about Type 2 and 3 comparison.

With Spring's autowire the configuration volume can be reduced for simple
cases (one object per type). Anyway, how dependencies are exposed has
nothing to do with how metadata configuration (if any) is stored. With more
complex (and realistic) cases Pico also requires configuration information.

I think the constructor style works well for simple objects (a small number
of dependencies, no likelihood of subclassing, and no configuration
parameters). However I think the JavaBeans approach scales better to the
complexity of typical application objects.

Anyway, part of the point of the changes is that we don't need to argue over
this any more. We will continue to recommend the use of JavaBeans as best
practice in most cases, but leave users to decide what they prefer.

I absolutely think the container should be responsible for configuration
properties, rather than just dependencies. In fact this was the first itch I
needed to scratch in starting to develop what become the Spring bean
factory. The alternative is likely to be ad hoc config lookups everywhere
and untestable code.

Regards,
Rod

----- Original Message ----- 
From: "Brian McCallister" <br...@ap...>
To: <spr...@li...>
Sent: Monday, November 10, 2003 1:21 AM
Subject: Re: [Springframework-developer] Type 3 IoC support


> On Sunday, November 9, 2003, at 05:47 PM, Rod Johnson wrote:
> > I think that although we should continue to advocate JavaBeans ("Type
> > 2") as
> > the best alternative in most cases, Type 3 is a good choice in a
> > minority of
> > cases. And in any case, the Spring philosophy is to be non-intrusive.
> > We
> > don't want to tell people how they should code.
>
> I am curious why you think that Type 2, JavaBean bases, IoC frameworks
> are a better option. I would tend to think that the more obvious
> constructor oriented dependency resolution is easier to work with and
> maintain. One of the things that has bothered me looking at Spring was
> the considerable volume of configuration xml compared to something like
> a PicoContainer.
>
> I don't think that the component container should be responsible for
> configuring the various components - only for supplying the
> dependencies and, maybe, lifecycle management. The component framework,
> to paraphrase yourself, should stay out of the way and not affect the
> components themselves. I see a a complex set of JavaBean style
> configuration options managed by the framework as a liability as far as
> this goes.
>
> -Brian
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>