Future of DI Framework [message #893376] |
Tue, 03 July 2012 14:34  |
Eclipse User |
|
|
|
I am working on creating a new application and struggling with whether to use the included DI framework or to use Google Guice.
What does the future hold for the included DI framework API?
In particular, I will be using "contexts" that span workbench parts. I am leaning more towards the combination of the two frameworks. Guice for the logical/business layer and the included DI for the presentation layer, and have Guice inject the e4-DI framework with the appropriate content where necessary.
Does anyone have any thoughts/recommendations on this matter?
Has anyone already attempted this? (examples?)
Thanks,
JD
|
|
|
Re: Future of DI Framework [message #893587 is a reply to message #893376] |
Wed, 04 July 2012 13:30   |
Eclipse User |
|
|
|
I briefly investigated (out of curiosity) whether Guice could be used in place of our DI engine, and it didn't appear to be an easy switch -- Guice expects rather static modules, meaning that the contents of the modules do not change after being configured, whereas E4's contexts change frequently. Even if we did switch to Guice, or some other injector, we'd be under heavy pressure to ensure compatibility with the E4 annotations.
The main annotations used for injection are standard (JSR 330), and supported by Spring, Guice, and others. So providing you restrict yourself to those, you can use your code interchangeably.
The main difference between the E4 injector and Guice, in terms of behaviour, is the use of the @Createable annotation to mark objects that can be auto created; Guice considers any object with a 0-art constructor to be auto-createable.
Hope that helps.
Brian.
|
|
|
|
|
Re: Future of DI Framework [message #894178 is a reply to message #893680] |
Sat, 07 July 2012 07:50  |
Eclipse User |
|
|
|
I think Sopot's touched on a lot of the issues that I see. My experience with Guice has been pretty limited, but I think using E4 contexts to configure Guice should be straightforward, providing the allies pulled from the contexts don't dynamically change or go stale. The key is to ensure that objects managed by one DI container are not provided to another DI container -- this happened somehow to some early adopters, though I think that was a configuration mistake on the developer's part.
Brian.
|
|
|
Powered by
FUDForum. Page generated in 0.11353 seconds