I agree with Hamelt here. I'm using Spring every day and I only use it with constructor injection.
However, if you are referring to the Spring Documentation, you are indeed right.
The Spring team generally advocates the usage of setter injection, since a large number of constructor arguments can get unwieldy, especially when some properties are optional.
One of the problems I face with Guice is the fact that a Provider only provides a #get() method. Is there a feature to pass in parameters to a variant of the get method like AssistedInject ? Does Spring have a comparable thing to Providers ?
@andorra Yes Spring has "Factory" interfaces, which are the same thing, but they are not available by default and are not type safe last I checked.
Spring also has an assisted inject equivalent with Factory methods (and interfaces), which uses method decoration. Again, it is a bit clunky but it's there.
@Hamlet Annotations != type safety JavaConfig is also not type safe, like Guice's binder API.
As for other features, Guice has much more compelling servlet and JPA stories, which are 90% of use cases in the kitchen sink.
i am using spring in my dayjob and guice in my pet projects, both for about half a year.
both have increased my productivity drastically.
spring seems to have an advantage at the business side - as a manager, you will recruit a spring expert easier than a guice expert.
on the other hand, it seems much easier to mess up the spring configuration, than the guice config. @Inject apeared more intuitive to my coworkers on the pet project than using the external config.
what bothers me in both cases: there seems to be a tendency to view the injector/webappcontext as a super-factory.
so i've seen the approach that should be used as a last resort more often than i should:
in 99% of the cases, this is wrong, since you could simply inject the right class using @Inject or as a < property >. effectively you transform your class to a top-level class by abusing the DI container this way.
...although I disagree with Jamis that DI is completely unnecessary (you can hear me on the video) - DI is still a valuable architecture, even in Ruby. Like testing, it generally leads programmers to do Good Things - such as loose coupling and high cohesion.
Unfortunately, most Ruby frameworks (such as Rails) are architected in a way that pretty much precludes the widespread or high-level use of DI in your app.
However, if you are not constrained by a framework, DI is an excellent way to structure your app. Start with a simple Registry pattern which builds your App and take it from there (like this: http://geminstaller.rubyforge.org/code/coverage/lib-geminstaller-registry_rb.html). Simple, maybe ugly, but the result of pure YAGNI TDD and completely functional (btw, this started out with Needle but I scrapped it because it was my only external dependency).
i am planning make my project on inversion of control/dependency injection.can anybody please suggest me from where actually my project should start????? reply as soon as possible...i need your help because i have understood the concept but unable to implement.
Don't forget Plexus. I think more people are unwittingly using Plexus every day than something like Pico, it is at the core of Maven.
OdpovedaťOdstrániťI'll defend Spring here...
OdpovedaťOdstrániťSpring has a very good deployment package and you can easily only include the DI jars and not include all the others. Don't use what you don't need.
Spring supports annotations, in fact I would have said it is the recommended configuration choice. There is no data to support the claim though.
Spring supports constructor injection, and again I would have said it is the recommended approach. No data though.
Spring also has great support for autowiring JUnit tests. Cool! Check it out: http://is.gd/gIcB
I agree with Hamelt here. I'm using Spring every day and I only use it with constructor injection.
OdpovedaťOdstrániťHowever, if you are referring to the Spring Documentation, you are indeed right.
The Spring team generally advocates the usage of setter injection, since a large number of constructor arguments can get unwieldy, especially when some properties are optional.
Spring has a JavaConfig that is in beta which allows one to use DI in Java (or Scala code for that matter) without using any XML.
OdpovedaťOdstrániťI understand it is possible to mix JavaConfig with XML, but I haven't done that on any of my projects.
One of the problems I face with Guice is the fact that a Provider only provides a #get() method. Is there a feature to pass in parameters to a variant of the get method like AssistedInject ? Does Spring have a comparable thing to Providers ?
OdpovedaťOdstrániť@andorra Yes Spring has "Factory" interfaces, which are the same thing, but they are not available by default and are not type safe last I checked.
OdpovedaťOdstrániťSpring also has an assisted inject equivalent with Factory methods (and interfaces), which uses method decoration. Again, it is a bit clunky but it's there.
@Hamlet
Annotations != type safety
JavaConfig is also not type safe, like Guice's binder API.
As for other features, Guice has much more compelling servlet and JPA stories, which are 90% of use cases in the kitchen sink.
Disclaimer: I am a Guice team member.
Dhanji.
@Dhanji
OdpovedaťOdstrániťCan you explain more the statement "JavaConfig is not ype safe". With JavaConfig, everything is done in Java code so it checks all the types.
@Blair
OdpovedaťOdstrániťOops, I meant to say JavaConfig *AOP* is also not typesafe.
Dhanji. =)
i am using spring in my dayjob and guice in my pet projects, both for about half a year.
OdpovedaťOdstrániťboth have increased my productivity drastically.
spring seems to have an advantage at the business side - as a manager, you will recruit a spring expert easier than a guice expert.
on the other hand, it seems much easier to mess up the spring configuration, than the guice config. @Inject apeared more intuitive to my coworkers on the pet project than using the external config.
what bothers me in both cases: there seems to be a tendency to view the injector/webappcontext as a super-factory.
so i've seen the approach that should be used as a last resort more often than i should:
StaticUtils.injectorFromservletContext(). getInstance( SomeDao.class );
SpringUtils.getBean("someDao");
in 99% of the cases, this is wrong, since you could simply inject the right class using @Inject or as a < property >. effectively you transform your class to a top-level class by abusing the DI container this way.
Use Ruby and you won't need a DI framework:
OdpovedaťOdstrániť* http://rubyconf.org/talks/18
* http://rubyconf2008.confreaks.com/recovering-from-enterprise.html
...although I disagree with Jamis that DI is completely unnecessary (you can hear me on the video) - DI is still a valuable architecture, even in Ruby. Like testing, it generally leads programmers to do Good Things - such as loose coupling and high cohesion.
Unfortunately, most Ruby frameworks (such as Rails) are architected in a way that pretty much precludes the widespread or high-level use of DI in your app.
However, if you are not constrained by a framework, DI is an excellent way to structure your app. Start with a simple Registry pattern which builds your App and take it from there (like this: http://geminstaller.rubyforge.org/code/coverage/lib-geminstaller-registry_rb.html). Simple, maybe ugly, but the result of pure YAGNI TDD and completely functional (btw, this started out with Needle but I scrapped it because it was my only external dependency).
-- Chad
We just developed a open source Light Weight Ioc / Dependency Injection framework. Can you have a look?
OdpovedaťOdstrániťhttp://blog.isilverlabs.com/2010/08/lightweight-ioc-dependency-injection-framework/
i am planning make my project on inversion of control/dependency injection.can anybody please suggest me from where actually my project should start????? reply as soon as possible...i need your help because i have understood the concept but unable to implement.
OdpovedaťOdstrániťplease let me know how to make framework using dependency injection??? and how to implement the concept of inversion control
OdpovedaťOdstrániť