On 14 avr, 11:42, Vitali Lovich <[email protected]> wrote:
> Actually, I'd be surprised if the dependancy injection implementation
> doesn't boil down to a form of deferred binding in the end for performance
> reasons (except using the Generators mechanism instead of explicit deferred
> binding).
That's not what Suco does, for instance, as it's entirely "client
side":
http://code.google.com/p/suco/
But as I said, that a DI framework work smoothly *on top of* deferred
binding is a must-have (or should-have), but deferred binding has in
essence nothing to do with either dependency management or any kind of
"injection", only with, well, deferring the type binding (which
concrete class to use as an implementation of a given abstract class
or interface, or which specialized class, if any, to use for a given
concrete class) to compile time [*] rather than "coding time".
I admit that there are crossing concerns between DI and deferred
binding (namely, code against an "interface", no matter which concrete
implementation you'll actually be running against), but DI has much
more: it's all about removing all explicit class instantiations from
your code (which also means removing scope management (singleton,
etc.) from your code), while deferred binding is only about choosing
the class that will actually be instantiated.
A key difference is that dependencies with deferred binding have to be
part of the interface you're coding against (be it an interface,
abstract class or concrete class; I'm using interface here as meaning
"contract"), and you still have to inject dependencies "by hand". With
DI, an interface/contract provides some "service", and the DI
framework will inject dependencies based on the actual class being
used.
Actually, deferred binding is "only" a kind of "optimization" to avoid
code à la "switch(GWT.getBrowser()) { case IE: ... break; case
Mozilla: ...; break; etc."
It's a wonderful tool, but it's just not dependency injection.
My opinion is that you should use deferred binding to have different
code paths depending on some runtime property (or eventually compile-
time: in GWT-in-the-AIR, you choose at compile time whether you
compile for AIR or browsers, and this has an impact on some deferred
bindings, such as FormPanel, and of course AIR.isRuntime(), which is
pretty similar to GWT.isScript() or GWT.isClient()), and use a DI
framework (my vote goes to GIN, but that's a personal taste)
otherwise, such as for a "testing environment"; but of course, YMMV.
[*] or you could say runtime, if you're generating multiple
permutations, though everything's done at compile time, and at runtime
bootstrap code only choose between already compiled bindings.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
