Weld, the JSR-299 Contexts and Dependency Injection reference implementation, considers itself as a kind of successor of Spring and Guice.
CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has its own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more web and enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from the frameworks mentioned and lots of collaboration and hard work by the JSR-299 Expert Group (EG).
http://docs.jboss.org/weld/reference/latest/en-US/html/1.html
What makes Weld more capable for enterprise application compared to Guice? Are there any advantages or disadvantages compared to Guice? What do you think about Guice AOP compared to Weld interceptors? What about performance?
My choice
In the end I decided to use Guice because I like the clean programming model which comes almost without annotations besides @Inject by default. It is much easier to use external libs with Guice than with CDI. AOP is also pretty simple with Guice.
Before trying to answer your question, let me just add an important piece of information: JSR 330 ( @Inject
) was standardized by Guice and Spring projects ( announcement from May 2009 ) and is being reused in JSR 299 . This covers basic DI mechanisms in terms of declaring an injection point.
Now, back to the question - with the disclaimer that I have far more experience with Spring than with Guice.
Enterprise capabilities in Weld
beans.xml
). Advantages / Disadvantages
Note: I will try to add a few items here later, but this answer is already longer than I had expected, sorry.
Weld/CDI
Guice/Spring
AOP and Interceptors
This is a very heavily discussed topic, and I cannot favor one over the other. Both mechanisms are very powerful but require at least a minimum understanding of the application's architecture. Also have look at Decorators and the previously referenced Events . It is best to go with the right tool, but don't forget that if a developer has to work with one of these mechanisms it is a good thing if he/she understands the concept.
Performance
Unfortunately I could not look into this yet, but there are a few rules I try to follow, especially when using a framework that gives you a lot of functionality without you noticing it:
CDI (Weld) hasn't yet been used widely, so a comparison is hard to make. A few points:
Guice用户的CDI是一个很好的比较。
The most important feature CDI has opposed to Guice, is that it is a standard part of Java EE 6.
The importance of this cannot be underestimated, as it means that CDI is the DI-standard you should use when coding web applications.
A while back I had a look at the technologies to be able to determine how we could have a standard core distribution - suitably prepared - where we could add extra modules at will which could override existing functionality without having to change the core modules. Ie add an extra jar, and the functionality activates automatically.
It turned out that the best way for us to do this for a code base used in both desktop and web applications, was to use JSR-330 annotations for our code, and then use either CDI or Guice (SVN, coming real soon now in 3.0) as the engine.
After a few projects I've found that I like the Guice configuration best instead of the opaque magic happening in Weld. Additionally I found that the way to do what we want as described above with Weld, I have to mark the class in the extra jar as @Alternative, and then mention in beans.xml that I want the alternative class enforced (and that is not robust against refactoring).
But, all in all, JSR-330 allows us to do something which was very tedious and fragile before (because new
binds so extremely tightly), and that is a great win. I can strongly recommend looking into DI if you have any need like this.
Another differentiator is that CDI is very Java EE oriented. It provides a mechanism to glue the different Java EE subsystems together.
Ie. By annotating a bean with @Named("book")
, the bean becomes known in the unified EL (Expression Language) as ' book
'.
Then you can use it in a JSF page for instance:
<h:outputLabel value="Book title:" for="bookTitle"/>
<h:outputText id="bookTile" value="#{book.title}"/>
I have used Guice in an AWS Lambda serverless application. AWS recommends using Guice or Dagger over Spring in a Lambda function. See AWS Lambda best practices
The primary reason is that Guice and Dagger are smaller frameworks and have faster start up time, which is essential in Lambda.
Although the OP hasn't mentioned Spring, both Spring and CDI/weld are meant for enterprise level applications, which often require additional features that these frameworks provide. Hence for smaller applications, which only require DI, Guice or Dagger would be optimal.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.