The inverse of IoC is Control
comoyo.github.com
The inverse of IoC is Control
1–10 of 66 posts
Re: The inverse of IoC is Control
#2Younger IoC frameworks aim for configuration in code, allowing for a much more dynamic usage.
Examples (c#) * Autofac * Ninject
Re: The inverse of IoC is Control
#3Younger IoC frameworks aim for configuration in code, allowing for a much more dynamic usage. Examples (c#) * Autofac * Ninject
We use Guice which also allows that. But that doesn't address some of the key points he makes, such as
- runtime x compile time wiring
- wiring is based on types so injecting differently set up instances is difficult (we have a hell of Providers and different annotations to pick the right kind of instance injected)
- non-transparency of the wiring process (sice it is performed by the magical IoC container)
I agree with a lot of what he writes. At the same time I believe there are cases where I would appreciate some kind of automation for wiring (f.ex. if I want a fresh instance for each session or request). And there are certainly cases when runtime wiring - as in the mentioned case of plugins - is useful.
Re: The inverse of IoC is Control
#4I'm pretty sure IoC here refers to "inversion of control" (http://en.wikipedia.org/wiki/Inversion_of_control). I had to look it up though, I find it a bit silly that even the original article doesn't spell this out in the first sentence.
I guess it's super-obvious from context (and the claim of the title) so I guess I'm just not very smart, today. Oops.
Re: The inverse of IoC is Control
#5Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations.
That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configuration file.
We opt for configuration files. We opt for IDEs that can interpret Spring configuration files which means typos or incorrect dependencies do show up. This allows us to swap out implementations in case shit goes down without having to recompile, connect over a VPN to a remote desktop and hop through a few more hoops to get our class file on the other side. If you're not running your own apps on infrastructure you control (we should be so lucky), you have to take this sort of stuff into account. I'd love to be able to say "This is how stuff's set up. Deal with it."
(And when shit goes down, it is usually not at the place you were expecting it to happen, which means all kinds of configuration options for your bootstrapper would probably still fall short.)
Re: The inverse of IoC is Control
#6I found that a sweet spot between wiring-by-code and wiring-by-container-and-configuration-dsl is using a dynamic language for wiring (say, Rhino, which is very lightweigth): you have the flexibility of wiring-by-code and can easily change the configuration purely by deployment (without recompiling anything)
Re: The inverse of IoC is Control
#7According to Martin Fowler [1], Inversion of Control is an alternative to using a Service Locator:
> In the Java community there's been a rush of lightweight
> containers that help to assemble components from
> different projects into a cohesive application.
> Underlying these containers is a common pattern to how
> they perform the wiring, a concept they refer under the
> very generic name of "Inversion of Control". In this
> article I dig into how this pattern works... and
> contrast it with the Service Locator alternative. The
> choice between them is less important than the principle
> of separating configuration from use.
(edit: Also, the Spring Framework has had alternatives to XML configuration for years: http://www.ibm.com/developerworks/webservices/library/ws-spr...)
Re: The inverse of IoC is Control
#8Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…
I agree with using IoC for different implementations, but I'm puzzled by those who want to use it everywhere, because it supposedly makes the code easier to test.
Guice is a nice IoC framework, but look at what they say on their website:
"Think of Guice's @Inject as the new new."
Re: The inverse of IoC is Control
#9I think the title's a bit misleading though... This guy is obviously talking about dependency injection.
Things like callbacks, observers, events, ... are also types of IoC.
Re: The inverse of IoC is Control
#10Younger IoC frameworks aim for configuration in code, allowing for a much more dynamic usage. Examples (c#) * Autofac * Ninject
We use Guice which also allows that. But that doesn't address some of the key points he makes, such as - runtime x compile time wiring - wiring is based on types so injecting differently set up instances is difficult (we have a hell of Providers and different annotations to pick the right kind of instance injected) - non-transparency of the wiring process (sice it is performed by the magical IoC container) I agree wi…
Ninject actually does allow you to wire up with criteria beyond type based on the context into which the object is being injected.