IOC Container build in code vs configuration.Advice needed

Question

I have not done much IOC but from what I read and the examples I see on the internet it has confused me.

My understanding is that you should use IOC to promote loosely coupled system.

Now building the container in code (Unity) the one my company uses how can this be decoupled if I have to have a hard reference to my service EG

   IUnityContainer container=new UnityContainer()
    .RegisterType<IMyService,MyService>();

As you can see MyService is a concrete class which will require me to have a reference to my service layer.

Am I not defeating the point now?

Any examples or suggestions or views very welcome

if you have registered types in your service layer with the container. Then container will create instances of those types needed to create your MyService instance. — Eranga, Jun 04 '11 at 10:01
Related: http://stackoverflow.com/questions/2512316/ioc-dependency-injection-please-explain-code-versus-xml — Mark Seemann, Jun 04 '11 at 21:08
Related: http://stackoverflow.com/questions/5267525/dal-bll-gui-composition-root-how-to-setup-di-bindings — Mark Seemann, Jun 04 '11 at 21:08

score 2 · Accepted Answer · answered Jun 04 '11 at 11:43

2

Container is helping you build loosely coupled applications, but loosely coupled doesn't mean "no hard references on other assemblies" as you seem to be suggesting.

Interface and class that implements it may live in the same assembly, in the same namespace, event in the same .cs file, and that has nothing to do with loose or tight coupling.

It's about the classes that use other types depending on abstractions, not on concrete implementations. The fact that your registration code has knowledge of both, abstraction and concrete implementation is ok. After all you need to have some coupling.

In terms of mechanics, you can simplify the registration and not mention both types each time, and even not have reference to other assemblies by using conventions in some other containers like Windsor (Unity doesn't support convention-based registration to the best of my knowledge).

Again - this is mechanics and has nothing to do with loose vs tight coupling or reasons for using containers. It just makes using the container simpler.

HTH

answered Jun 04 '11 at 11:43

Krzysztof Kozmic

27,267
12
73
115

"no hard references on other assemblies" as you seem to be suggesting." this is exactly my point.I really thought that.I did see a post by a guy cannot find the link now that advocated just that.The only point of a IOC is not to use concrete implementation – user712923 Jun 04 '11 at 12:15
you are right.There is a lot to learn,but hey difficult to find best practices where you are learning by yourself. – user712923 Jun 04 '11 at 12:53
check out Windsor's documentation. It doesn't just talk about using the API but also about patterns, suggested usages, pitfalls, etc. – Krzysztof Kozmic Jun 04 '11 at 13:08
Have a look at this link and tell me what you think http://anderly.com/2010/11/09/asp-net-mvc-dependency-injection-and-the-bliss-of-truly-decoupled-applications/ – user712923 Jun 04 '11 at 18:39

score 0 · Answer 2 · answered Jun 04 '11 at 12:05

Taking an example of an MVC app, the configuration

UnityContainer container = new UnityContainer()
    .RegisterType<IMyService, MyService>();

would be created when the application starts, and the benefits come when you use IMyService in, for example, a controller:

public class MyController : Controller
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    } 

    public ActionResults Index()
    {
        var model = _myService.GetModel();
        return View(model);
    }
}

Compare this to a system that uses it this way:

public ActionResults Index()
{
    var model = new MyService().GetModel();
    return View(model);
}

Now you're married to that implementation. Unit testing becomes very difficult now as there's no way to mock IMyService.

Thanks for your reply.That is all good but that means that I need to add reference to the assembly where MyService Resides,therefore we are coupling now.Am I wrong?Using Config I would not need to add reference Am I missing the obvious? — user712923, Jun 04 '11 at 12:08
@user712923: Well, you have to have _some_ coupling between systems otherwise they aren't going to be useful. References aren't that big of a concern, IMHO, as long as you're smart about it. Avoiding the reference using config is fine too (like Microsoft does with providers) but you'll still need to access that assembly at runtime--you still depend on it being in the bin or GAC. — ataddeini, Jun 04 '11 at 12:23

score 0 · Answer 3 · answered Jun 05 '11 at 01:53

The main concept at work, when you build up your IoC container through code, is that of Instability. Instability is a metric for Object-Oriented systems measuring the ratio of Efferent coupling to total coupling. It is most useful when applied at the "deployment package" level - which for .NET is the assembly.

When using this metric, the goal is not to achieve low Instability all of the time, but but rather to increase the Stablility of some assemblies (close to 0 Efferent coupling) by aggregating the Instability into other assemblies.

Depending on the platform you are working with, your .Exe (or the assembly containing your HttpApplication, ServiceHost, etc.) should assume the responsibility of managing Application startup, Application shutdown, and aggregation of all of the dependencies including building up your IoC (this will make it easier during deployment since the basic deployment scenario requires that your runtime project references any dependencies).

It is possible to configure your IoC using configuration files, thus saving your main application from potentially huge amounts of coupling, but the tradeoffs are as follows:

You lose the ability of manually building up an instance (perhaps performing some initialization that would be difficult through config) before registering the instance to be resolved against its interface.
Build checks - for instance mistyping the Class name or Interface name.
Ease of deployment. If you are not referencing the assemblies containing the interface implementations in your main project, you will have to manually deploy them or manually add them to your setup project (if you are using one). This may be more or less of a problem depending on the environment and any existing deployment processes that may be in place.

IOC Container build in code vs configuration.Advice needed

3 Answers3