| Future of DI Framework [message #893376] |
Tue, 03 July 2012 18:34  |
|
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 17:30  |
 Brian de Alwis
Messages: 242
Registered: July 2009 |
Senior Member |
|
|
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 #893628 is a reply to message #893587] |
Thu, 05 July 2012 02:53 |
|
Brian-
I have to apologize, I don't think I stated my question very well.
I am certainly planning on utilizing the e4 DI container. Actually, I spent the better part of the day reading through Lars' documentation and looking at the source to get a good feel for it.
Maybe better stated: In what situations would you (personally) want to bring in an external DI engine like Guice?
What do you (personally) see the in the future of the e4 DI container?
I am developing an xtend/xtext application that will utilize DI heavily, and I am unsure of whether to have the business tier in a completely separate (external) DI engine or to create a "biz" context within the e4 container.
Thoughts?
Thanks,
JD
jfyi- I am working on creating an eclipse based financial research platform
|
|
|
| Re: Future of DI Framework [message #893680 is a reply to message #893628] |
Thu, 05 July 2012 08:56 |
Eclipse User |
|
|
|
Joseph,
A DI container's purpose is to delegate elsewhere (not your app code) the creation of your dependencies. In my opinion this means that there is no difference if you are using it as a pattern in building your GUI or your data model.
You would probably use an external DI container if the provided one does not suit your needs. xtend and xtext itself are built using Guice so if you use them, you will have Guice anyway but under the hood.
Another point is that, if default DI doesn't suit your needs, Eclipse's DI is relatively easy to extend to suit your domain specific needs, be it by creating your special annotations or by creating your own context functions (your F in received=F(requested))
Also the context hierarchy is really useful in managing your domain model. If you use it for your application data model you will have the possibility to scope and isolate the parts' access to only what they need and not some "everyone can access everything" approach.
The event brokering mechanism is another thing from which your application's domain model can profit from. DI powered event brokering will assist you in managing the changes in your data and publish them to the appropriate listeners. If you use separate containers it may be really difficult to synchronize model-GUI changes (even though it may be managed at OSGi events level).
I wouldn't consider your "biz" and "gui" completely separate. It is true that you have to respect coupling and stuff but DI (any DI) will take care of decoupling the *creation* of your dependencies, but at some point in time you will have to have these things near each other, communicating and synchronizing so having them managed by the same container I think is a better idea.
I haven't used Guice so this was an Eclipse 4 DI show off rather than a comparison but I have a feeling that Eclipse's container is built specifically for RCP stuff and it may be more suitable.
Hope this helps you decide.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03538 seconds
] 
Search
Help
Register
Login
Home
