IoC.Resolve vs Constructor Injection

I heard a lot of people saying that it is a bad practice to use IoC.Resolve(), but I never heard a good reason why (if it's all about testing than you can just mock the container, and you're done).

now the advantages of using Resolve instead of Constructor Injection is that you don't need to create classes that have 5 parameters in the constructor, and whenever you are going to create a instance of that class you're not gonna need to provide it with anything

IoC.Resolve<> is an example of the Service Locator pattern. That pattern imposes a few restrictions that constructor injection does not:

• Objects can have no more fine-grained context than the application domain, due to the static calls
• Objects decide which versions of dependencies to resolve. All instances of a certain class will get the same dependency configuration.
• The temptation to couple code to the container is high, for example instead of creating an intention-revealing factory.
• Unit testing requires container configuration, where the classes could just be created and used otherwise. (This is especially troublesome when you want to test multiple configurations of the same class, due to the second issue above.)
• An application's structure cannot be inferred from its public API. (Constructor parameters are a good thing. They are not a problem you should feel the need to solve.)

These limitations, in my mind, relegate the Service Locator pattern to a middle ground between big-ball-of-mud and dependency injection: useful if you must use it, but by far not the best choice.

If you create classes that have 5 dependencies, you have problems other than IoC.Resolve.

Pulling dependencies (as opposed to having them pushed via constructor) completely misses the point of using IoC framework. You want to invert the dependencies. Not have your classes depend on IoC framework, but the other way around.

If you don't need all dependencies in certain scenarios, than perhaps you should split your class, or have some dependencies made optional by making them property dependencies.

Your classes depend on the container. They won't work unless you provide them with one. Whether it's a real one, or a fake one does not matter. They are inherently bound to the container via static dependency. This imposes additional work on you to do anything with your classes. Any time you want to use your class, you need to drag the container with them. For no benefit! Service locator is just one global bag of everything, which is against probably all tenets of object oriented programming.

Ioc.Resolve is essentially the Service Locator pattern. It has its place, but is not ideal. Constructor injection is preferred from an architecture standpoint, as dependencies are more explicit, whereas the SL hides the dependencies within a class. This reduces testability, and makes the process more complex than it needs to be.

If I may, I would suggest you read my series on techniques to reduce code coupling, which covers SL, DI, and IoC.

One advantage is that with constructor injection, all class dependencies are visible up-front.

With .Resolve you have to read the code just to figure the dependencies out.

I have to point out it's not necessarily evil to skip constructor injection and use static injection. There are great applications of this, the most concrete example is using it in a Factory pattern implementation.

public static class ValidationFactory
{
    public static Result Validate<T>(T obj)
    {
        try
        {
            var validator = ObjectFactory.GetInstance<IValidator<T>>();
            return validator.Validate(obj);
        }
        catch (Exception ex)
        {
            var result = ex.ToResult();
            ...
            return result;
        }
    }    
}

I use this with StructureMap to handle my validation layer.

Edit: Another example I have of using the container directly is to make some of your domain objects be singletons without making them static classes and introducing all the wierdness that static classes do.

In some of my views I wire up some entities like this. Normally I would us a Enum with a Description attribute to give me 3 value choices but the 3rd one in this case needs to be a string also and not an int so I created an interface with those 3 properties and inherit all of the domain objects from it. Then I have my container scan my assembly and register all of them automatically then to pull them out I just have

SomeObject ISomeView.GetMyObject
{
    get { return new SomeObject { EmpoweredEnumType = 
            ObjectFactory.GetNamedInstance<IEmpEnum>("TheObjectName");
        }
}