Does an IoC Container affect the design of an application using Dependency Injection?

Question

Is it safe to say that a Container is the "program" or mechanism that manages IoC via DI, but it doesn't really change your initial design of DI to accomplish loose coupling?

In other words, if I want to achieve loose coupling, say for a Logger, using a Container doesn't change that. It just manages it in case I had a lot of dependencies to construct a class (less typing, more manageable, better Unit testing, etc.)

It won't change the fact that I have interfaces and contracts with ILogger or IDatabase, for example, correct?

//Assume I have to interfaces and two classes that implement them
Class DemoDI
{
    ILogger myLogger;
    IDatabase myDatabase;

    DemoDI(ILogger myLogger, IDatabase myDatabase)
    {
        this.myLogger = myLogger;
        this.myDatabase = myDatabase;
    }

    //Methods that do stuff with the logger and database
}

I'm asking if that wouldn't change, that design pattern. It's just that somewhere, (main?), I would (say with Unity)

ioc.RegisterType<ILogger MyLoggingClass>(new ContainerControlledLifetimeManager());
ioc.RegisterType<IDatabase MySQLDatabaseClass>; //transient by default

And, if MySQLDatabaseClass had,

interface IDatabaseConnection
{
    void GetConnection();
}
Class DataConnection : IDatabaseConnection
{

    public void GetConnection()
    {
        //Get a connection
    }

}
Class MySQLDatabaseClass
{
    DataConnection myConn;

    MySQLDatabaseClass(DataConnection myConn)
    {
        this.myConn = myConn;
        this.myConn.GetConnection();
    }
    //Do other things;


}

Then the Container would wire that up too, assuming I had a:

ioc.RegisterType<IDatabaseConnection, DataConnection>();

If not I'd have to do it all by hand. The container is the helper that makes it nice and neat and assembles it all.

Now, if I want to Unit test the database class I would just have to adjust my container:

ioc.RegisterType<IDatabase MyMockedUpMySQLDatabaseClass>; //transient by default

Do I understand the purpose of an IoC Container correctly? Hopefully, I didn't get too lost in my dependencies.

Answer 1

Is it safe to say that a Container is the "program" or mechanism that manages IoC via DI, but it doesn't really change your initial design of DI to accomplish loose coupling?

IoC and DI will change any design that didn't previously follow them. Using a container shouldn't change your design but it often does. Some containers demand you spread knowledge of the container throughout your code base. You end up trading one one set of dependencies for another. You shouldn't be able to look at a class and tell what container is involved. If you can, well now you're dependent on that container.

IoC and DI do not require a management container. You can manage them best by understanding what they are rather than expecting a container to do your thinking. You can manage them with a container but that's your choice.

Foo foo = new Foo( new Bar() );

That right there is a dependency injection. Foo depends on Bar, or at least some kind of Bar like thing. Foo can't exist without it. Bar is a dependency. Since Bar is being passed to Foo, Bar is a dependency that's been injected.

IoC is a complicated way to say: don't hard code knowledge of an implementation. If Foo built it's own Bar, Foo would be hard coded to Bar and Foo couldn't accept new kinds of Bar but if Foo doesn't know about Bar, just an interface, then Bar can be changed without touching Foo.

There are many way's to not hard code a dependency (follow IoC):

• Factory pattern
• Service locator pattern
• Dependency injection,
• Constructor injection
• Parameter injection
• Setter injection
• Interface injection
• Contextualized lookup
• Template method design pattern
• Strategy design pattern

You can do this stuff in a container. You can do it in construction code. You can do it in main.

Wherever you do it, please don't mix this construction code with behavior code. Hard wiring together stuff the moment you feel like it creates the mess that started this overblown container movement in the first place. It's a real problem. The best solution is to understand that you can fix it yourself.