bastiat
bastiat

Reputation: 2071

Sample IoC, that is not DI

Dependency Injection is some form of Inversion of Control.

  1. Could somebody please specify some other form of Inversion of Control, that is not a dependency injection ?
  2. Is there any java framework that is IoC container, but is not a DI container ?
  3. Which part of spring is IoC, but not a DI ?

Upvotes: 5

Views: 363

Answers (1)

Steven
Steven

Reputation: 172626

Inversion of Control is the ability to allow a framework to run your custom code. As Martin Fowler says here:

Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it's often seen as a defining characteristic of a framework.

So this is an example of Inversion of Control:

public class HomePage : Page
{
    protected override void OnPageLoad(object sender, EventArgs e) {
        // here your custom code
    }
}

Here we have some custom class that 'by some convention' the framework (ASP.NET Web Forms in this case) picks up and it runs our custom code. The way it is done here is by inheritance and overriding virtual methods of the base class that the framework provides.

So this is an other example of Inversion of Control:

public class HomeController : Controller
{
    public ActionResult Save(HomeSaveModel model) {
        // here your custom code
    }
}

Here we have our own custom controller where again the framework will call our code by some convention. Here we still use a base class given by the framework, but now the framework will call our Save action using reflection.

Inversion of control is all about hooking into framework code. Do note that in the examples above there is no dependency injection what so ever (nor is there Service Location).

Is there any java framework that is IoC container, but is not a DI container ?

The name "IoC container" is misleading, because those tools are meant to help you wire the dependency graphs in your application and do not help you wiring your code to a framework. IoC is a property of a framework; if it doesn't do IoC, it's not a framework: it's a library. Therefore "IoC containers" are libraries, not frameworks and they usually have no relationship with frameworks that we use (such as web frameworks such as ASP.NET).

So in this sense, there is no such thing as an "IoC container", since this is something that they can't do; by definition. In that context, your question stopped making sense :-), but to still answer it: no, "IoC containers" are always "DI containers" but never "IoC containers".

Upvotes: 3

Related Questions