10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Rob Thornton on Mar 27, 2007
Now that the dust has settled a bit from the initial release of Guice, the comparisons with Spring IoC and specifically with Spring JavaConfig are available. Guice and JavaConfig offer different approaches on putting IoC configuration into code using Java annotations.
Spring JavaConfig, which is currently at a 1.0 Milestone 1 release, is based on the sam idea as Guice in that moving away from XML configuration and towards annotations is good in that it puts the knowledge of the configuration closer to the code. Tapestry's IoC container is designed along the same lines.
JavaConfig and Guice come from very similar backgrounds. In fact, Bob Lee has written about their history:
I also have a slightly interesting anecdote: in the very early days, Guice looked very much like Spring's JavaConfig, which isn't surprising considering Rod showed me Spring's JavaConfig almost a year ago (and I showed him Guice about 6 months ago). Just like with JavaConfig, you wrote explicit Java code to wire your objects. I originally introduced @Inject as an optional way to double-check that the external code called all your setters as expected. Once we had @Inject, I asked, why do we need to write explicit wiring code at all? Shortly thereafter, we had the Guice you all know today.
Several posts comment on the differences between Guice and JavaConfig. Debasish Ghosh sums it up nicely when he writes:
The main difference between Guice and Spring lies in the philosophy of how they both look at dependencies and configuration. Spring preaches the non-invasive approach and takes a completely externalized view towards object dependencies. In Spring, you can either wire up dependencies using XML or Spring JavaConfig or Groovy-Spring DSL or some other option like using Spring-annotations. But irrespective of the techniques you use, dependencies are always externalized.
Guice, on the other hand, treats configuration as a first class citizen of your application model and allows them right into your domain model code. Guice modules indicate what to inject, while annotations indicate where to inject. You annotate the class itself with the injections (through @Inject annotation). The drawback (if you consider it to be one) is that you have to import com.google.inject.* within your domain model. But it ensures locality of intentions, explicit semantics of insitu injections through metadata programming.
Through numerous comment threads on these posts you find that the philisophical difference is the biggest thing to be aware of when making a choice between these two frameworks. How close to your code do you want your injections to be? With Guice, your code will be tied to the container, which some people will like an some won't. Guice claims to be faster, however it is noted that Spring's IoC container (whether JavaConfig or otherwise) allows for a full range of hooks that Guice does not. Spring also offers much more than IoC, while Guice does not try to solve such large problems.
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Besides this two, there is Spring-Annotations too ...:
It has moved to a new home, but still in active development
Spring-Annotations, it uses the Spring Framework engine, but enables all the configuration to be made using annotations
for example:
<bean id="test" class="br.com.test...." auto-wire="byName"/>
is equivalent to @Bean(name="test") in the class ...
Guice seems like a mix of Spring's "byType" autowiring with a mandatory @Required annotation (which is optional), plus Spring-annotation's automatic classpath scanning ability.
I mean, you take Spring, take all its power and flexibility away, put one (nice) little new feature in, say it's from Google, and that's it, you have now a Spring killer!
Whatever...
I was confused and thought JavaConfig was yet another IoC framework...
Adding "Spring" in front of "JavaConfig" would make it clearer...
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
3 comments
Watch Thread Reply