Re: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

Brian,

I've just changed the XmlBeanFactory id resolution to allow for "bean" =
tags with neither "id" nor "name", using the bean class as implicit id =
(PicoContainer-style). Spring's configuration XML can generally be =
adjusted to just the level that is needed, even more now that you don't =
need to specify ids for autowired components. Let's consider a few =
examples.

In the autowiring case, with automatic resolution of bean properties =
that express dependencies for other components, like a =
"setProductService(ProductService)" method in MyOrderService:

  <beans default-autowire=3D"byType">
    <bean class=3D"product.MyProductService"/>
    <bean class=3D"order.MyOrderService"/>
  </beans>

In the autowiring case, with automatic resolution of constructor =
arguments that express dependencies for other components, like a =
"MyOrderService(ProductService)" constructor in MyOrderService:

  <beans default-autowire=3D"constructor">
    <bean class=3D"product.MyProductService"/>
    <bean class=3D"order.MyOrderService"/>
  </beans>

In both cases, the MyOrderService instance can be retrieved via =
getBean("order.MyOrderService").

With explicit references via bean properties instead of autowiring:

  <beans>
    <bean id=3D"myProductService" class=3D"product.MyProductService"/>
    <bean id=3D"myOrderService class=3D"order.MyOrderService">
      <property name=3D"productService"><ref =
bean=3D"myProductService"/></property>
    </bean>
  </beans>

With explicit references via constructor arguments instead of =
autowiring:

  <beans>
    <bean id=3D"myProductService" class=3D"product.MyProductService"/>
    <bean id=3D"myOrderService class=3D"order.MyOrderService">
      <constructor-arg><ref =
bean=3D"myProductService"/></constructor-arg>
    </bean>
  </beans>

Here, the MyOrderService instance can be retrieved via =
getBean("myOrderService").

It's hard to imagine an XML-based NanoContainer with PicoContainer =
underneath that beats that level of conciseness. DefaultPicoContainer =
has programmatic registration of components; you can have that with =
Spring's ListableBeanFactoryImpl too. It's hard to see why you would =
prefer programmatic registration to concise XML in any considerably =
large application, though.

Essentially, both a PicoContainer and a Spring bean factory need =
configuration metadata, even exactly the same level depending on your =
configuration needs: component classes, component ids, specific =
parameters. No matter how hard the Pico guys claim "no configuration =
metadata" - this depends on your needs, and Pico and Spring have =
comparable volumes of metadata in that respect.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Brian McCallister
Sent: Monday, November 10, 2003 2:22 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC
support - Email found in subject


On Sunday, November 9, 2003, at 05:47 PM, Rod Johnson wrote:
> I think that although we should continue to advocate JavaBeans ("Type=20
> 2") as
> the best alternative in most cases, Type 3 is a good choice in a=20
> minority of
> cases. And in any case, the Spring philosophy is to be non-intrusive.=20
> We
> don't want to tell people how they should code.

I am curious why you think that Type 2, JavaBean bases, IoC frameworks=20
are a better option. I would tend to think that the more obvious=20
constructor oriented dependency resolution is easier to work with and=20
maintain. One of the things that has bothered me looking at Spring was=20
the considerable volume of configuration xml compared to something like=20
a PicoContainer.

I don't think that the component container should be responsible for=20
configuring the various components - only for supplying the=20
dependencies and, maybe, lifecycle management. The component framework,=20
to paraphrase yourself, should stay out of the way and not affect the=20
components themselves. I see a a complex set of JavaBean style=20
configuration options managed by the framework as a liability as far as=20
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