On 6/15/06, John Patterson <[EMAIL PROTECTED]> wrote:
i dont mind but maybe you should spin any future messages into a different thread.
also it is not going to really work comparing pico and spring because spring is sooo much more then just ioc.
first of all let me say that spring's xml config drives java classes, at least from what i have seen and i havent looked very hard. so if you want to use spring without xml that should be doable. see GenericApplicationContext.registerBeanDefinition()
spring can "autowire" dependencies just like pico, it would go something like this if you are using xml:
<bean class="foo.Bar" autowire="byType"/> analogous to pico setter injection
or
<bean class="foo.Bar" autowire="constructor"/> analogous to pico constructor injection
and there you have it. i dont know if semantics are exactly the same but they should be pretty close since there isnt that much playroom. something for you to experiment with.
yeah, it seems like setter injection is the preferred way in spring. i guess what setter injection gives you that constructor injection doesnt is the name of the setter itself, so it gives your config more context:
<bean ...>
<constructor-arg index="0" ref="dep0"/>
<constructor-arg index="1" ref="dep1"/>
</bean>
this doesnt convey as much information as
<bean ....>
<property name="userManager" ref="dep0"/>
<property name="securityManager" ref="dep1"/>
</bean>
and this is what the spring xml configuration is all about. one) it gives you a big overview of how the services are connected - there is a nice eclipse plugin that creates a cool graph from the xml file that gives you a birds eye of the infrastructure of your app - something not really possible to do when configuring in code, and two) the configuration is externalized - these things tend to be the things that would change from deployment to deployment so you really dont want them to be configured in code - ie swapping a HibernateUserDao for a LdapUserDao because one company wants you to hook in to their ldap dir, and this is where setter injection is also very useful ...
<bean id="userdao" calss="com.foo.user.HibernateUserDao">
<property name="sessionFactory" ref="hsf"/>
</bean>
vs
<bean id="userdao" class=" com.foo.user.LdapUserDao">
<property name="server" value="foo"/>
<property name="username" value="user"/>
<property name="password" value="pass"/>
</bean>
see, not only can you switch things out between deployments but you can also configure them. if you wanted this func then you would have to maintain your own property file that ldapdao would have to read, etc, etc. this way things are in a single place.
i havent used this pattern in a long time and havent tried it with spring so i dont know. creating container from xml file is pretty simple, new FileSystemXmlApplicationContext(" file.xml") is all it takes
but to summarize the whole thing:
if you dont care about externalizing your config or having visibility into how things are wired and all you need is ioc then pico is def the way to go. its best of breed for lightweight ioc containers, and the factory interface makes it pretty darn easy to customize how beans are managed inside the container.
if you do want externalizable config (the pico addon projects that provide this kinda suck imho) or you want a good base to build infrastructure for then spring is the way to go. it has a bunch of very well integrated modules that you might not need in the beginning of the project but you might need later like remoting, mail, jmx, jms, aop, event system for services, etc. these modules have saved me a ton of time on more then one occasion when i didnt think id need them but later - woops , and i can drop them in with just a few lines of xml. and having a global overview of how things are wired is also nice i think. i really hate xml, but if you use spring for a while you figure out shortcuts that save you from writing a lot of it. and in 2.0 they have different schemas for different modules which is pretty darn cool, it cuts down on xml and makes the xml itself more domain specific so its much more readable.
pfew, this ended up longer then i wanted. i dont know how unbiased this is, i really like spring. on the other hand i have used both so there is something to be said for that. take it anyway you want :)
-IgorIgor, sorry to turn this into a Spring Q&A! I understand if you don't want to discuss Spring on this list but it is hard to get an unbiased opinion on theirs.
i dont mind but maybe you should spin any future messages into a different thread.
also it is not going to really work comparing pico and spring because spring is sooo much more then just ioc.
I have only briefly looked at Springs IoC and was put off by the amount of configuration XML I would have to write. I use Picocontainer which is very simple to configure in Java alone because it makes lots of default assumptions about how to build an object without me having to specify.
first of all let me say that spring's xml config drives java classes, at least from what i have seen and i havent looked very hard. so if you want to use spring without xml that should be doable. see GenericApplicationContext.registerBeanDefinition()
spring can "autowire" dependencies just like pico, it would go something like this if you are using xml:
<bean class="foo.Bar" autowire="byType"/> analogous to pico setter injection
or
<bean class="foo.Bar" autowire="constructor"/> analogous to pico constructor injection
and there you have it. i dont know if semantics are exactly the same but they should be pretty close since there isnt that much playroom. something for you to experiment with.
Do you have any insight about how easily Spring can be configured in comparison to Pico? I could see that the examples were almost exclusively using setter injection but I much prefer to use constructors.
yeah, it seems like setter injection is the preferred way in spring. i guess what setter injection gives you that constructor injection doesnt is the name of the setter itself, so it gives your config more context:
<bean ...>
<constructor-arg index="0" ref="dep0"/>
<constructor-arg index="1" ref="dep1"/>
</bean>
this doesnt convey as much information as
<bean ....>
<property name="userManager" ref="dep0"/>
<property name="securityManager" ref="dep1"/>
</bean>
and this is what the spring xml configuration is all about. one) it gives you a big overview of how the services are connected - there is a nice eclipse plugin that creates a cool graph from the xml file that gives you a birds eye of the infrastructure of your app - something not really possible to do when configuring in code, and two) the configuration is externalized - these things tend to be the things that would change from deployment to deployment so you really dont want them to be configured in code - ie swapping a HibernateUserDao for a LdapUserDao because one company wants you to hook in to their ldap dir, and this is where setter injection is also very useful ...
<bean id="userdao" calss="com.foo.user.HibernateUserDao">
<property name="sessionFactory" ref="hsf"/>
</bean>
vs
<bean id="userdao" class=" com.foo.user.LdapUserDao">
<property name="server" value="foo"/>
<property name="username" value="user"/>
<property name="password" value="pass"/>
</bean>
see, not only can you switch things out between deployments but you can also configure them. if you wanted this func then you would have to maintain your own property file that ldapdao would have to read, etc, etc. this way things are in a single place.
Also, how easy is it to set up containers that manage object life-cycle at different scopes?
i havent used this pattern in a long time and havent tried it with spring so i dont know. creating container from xml file is pretty simple, new FileSystemXmlApplicationContext(" file.xml") is all it takes
but to summarize the whole thing:
if you dont care about externalizing your config or having visibility into how things are wired and all you need is ioc then pico is def the way to go. its best of breed for lightweight ioc containers, and the factory interface makes it pretty darn easy to customize how beans are managed inside the container.
if you do want externalizable config (the pico addon projects that provide this kinda suck imho) or you want a good base to build infrastructure for then spring is the way to go. it has a bunch of very well integrated modules that you might not need in the beginning of the project but you might need later like remoting, mail, jmx, jms, aop, event system for services, etc. these modules have saved me a ton of time on more then one occasion when i didnt think id need them but later - woops , and i can drop them in with just a few lines of xml. and having a global overview of how things are wired is also nice i think. i really hate xml, but if you use spring for a while you figure out shortcuts that save you from writing a lot of it. and in 2.0 they have different schemas for different modules which is pretty darn cool, it cuts down on xml and makes the xml itself more domain specific so its much more readable.
pfew, this ended up longer then i wanted. i dont know how unbiased this is, i really like spring. on the other hand i have used both so there is something to be said for that. take it anyway you want :)
_______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
