RE: [Springframework-developer] Type 3 IoC support

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Brian,

I still favour the bean style too: Fot example, having to pass 2 =
separate DataSource instances in via constructor argument indizes is a =
nuisance - it's much nicer if you can have "productDataSource" and =
"inventoryDataSource" bean properties. And with simple configuration =
parameters, it is extremely important to have proper naming: a =
(String,String,String) constructor isn't really self-explanatory, but =
"setUsername"/"setPassword"/"setUrl" is.

I consider applying simple configuration parameters as a major =
responsibility of a lightweight container. Like Rod says, the =
alternative would be ad-hoc reading in and parsing of properties files - =
why prefer that to strongly-typed bean properties of type String/int/etc =
that get set by the container? Spring also supports setting values from =
properties files, BTW: You can leverage PropertyPlaceholderConfigurer =
and leave placeholders in your bean definitions, to be resolved as keys =
in a properties file at runtime. In any case, your components don't have =
to care.

An example for handling simple configuration properties in a Spring =
application context:

  <!-- framework bean, not to be referenced by application objects -->
  <bean id=3D"myConf" =
class=3D"org.springframework.context.config.PropertyPlaceholderConfigurer=
">
    <property =
name=3D"location"><value>WEB-INF/my.conf</value></property>
  </bean>

  <!-- resource bean, to be referenced by data access objects -->
  <bean id=3D"dataSource" =
class=3D"org.apache.commons.dbcp.BasicDataSource">
    <property =
name=3D"driverClassName"><value>${dbdriver}</value></property>
    <property name=3D"url"><value>${dburl}</value></property>
    <property name=3D"username"><value>${dbuser}</value></property>
    <property name=3D"password"><value>${dbpw}</value></property>
  </bean>

The my.conf properties file contains the following entries, targetted at =
system administrators:

  dbdriver=3Dcom.mysql.jdbc.Driver
  dburl=3Djdbc:mysql://myhost:3306/mydb
  dbuser=3Dmyuser
  dbpw=3D

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, November 10, 2003 9:49 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Type 3 IoC support

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

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