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
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