Should I encapsulate my IoC container?

Question

I am trying to decide if it makes sense to go through an extra effort to encapsulate my IoC container. Experience tells me that I should lay a layer of encapsulation between my applications and any third-party component. I just don't know if this borders on excess.

I can think of situations where I can switch containers. For example, my current container is no longer supported, or another container is proven to be lighter / more efficient and better suited to my needs. If this happens, I will potentially have a lot of reconnection.

To be clear, I consider encapsulation of registration and type resolution. I believe that this does not require permission encapsulation - I would hope that in normal practice there is delegation of the helper / utility class to the container.

EDIT:

It is suggested that I prefer to plug in my types programmatically for type safety, compile-time checking, and refactoring. This is this code and its dependence on the container from which I want to protect myself.

I also used the IoC container for several other projects that share a lot of the same relationship, but the container is a pain to work with, so I want to change. But the change means that I am losing the possibility of reusing the registration code. Therefore, why am I considering encapsulation. This is not a huge burden, but the fact that I, nevertheless, would like to mitigate.

I'm looking for:

• Minimize the impact of changes in containers / container versions.
• Provide some level of consistency in registering types in projects that can use different containers.
• Provide interface methods that make sense to me (RegisterSingleton <T, T>, not RegisterType <T, T> (SomeLifetimeProvider) - using Unity as an example).
• Enlarge the container when conditions / scalability change, e.g. adding better caching, logging, etc. at the time of authorization / registration.
• Provide my own model for registering type mappings.
  • Suppose I want to create a bunch of RegistrationHandler objects in an assembly / package, and so I can easily separate the registration responsibilities from several classes and automatically intercept these handlers without changing the code elsewhere.

I understand that this is a bit subjective, so the pros / cons can be useful

Thanks!

Answer 1

Do this later, and only if you really need to change IOC containers.

Choose an IOC container that is not invasive. That is, when objects connected to each other have no dependencies on the IOC container. In this case, there is nothing to encapsulate.

If you need to select an IOC container that requires you to have container dependencies, select one with the simplest dependencies / APIs. If you need to replace this IOC container (and you probably won't), implement adapters that connect the new API to the old one.

In other words, let the first IOC container be the one that defines the interfaces for any future container, so you don’t need to invent your own, and you can postpone any of these works until you need it,

EDIT:

I see no way to guarantee security by type:

• Developing a relatively complex implementation of the Builder template along with visitor implementations that will write IOC configuration files or something equivalent.
• DSL implementation with IOC type configuration. (My choice is if I had several applications requiring replacement of IOC containers.)

Answer 2

Yes, I go. This is not a lot of extra effort and, as you say, it gives you better isolation from third-party components.

It also means that you can easily disable the IoC container if you find something better. I recently did this with replacing the Spring.net IoC container for the structure.

The ASP.NET MVC Contrib project on Codeplex is a good start. This is what I based my implementation on.

Answer 3

It is best to do something only if there is a real need for it, and never encode what you assume is sometimes required in the future (that the so-called YAGNI is a principle). If your architecture is fine, you can easily change the container if it really becomes necessary ...

If you think that you need such flexibility, you can look at the Local Service Project> in CodePlex. It does exactly what you are looking for: providing a common facade for the various IoC containers.

NTN!

Answer 4

Instead of encapsulating the IOC container itself, I prefer to isolate the locus of interaction with the IOC container. For example, in ASP.Net MVC, I usually limit the exposure of the container to the factory controller and the global.aspx.cs file, where it is usually configured.

In my opinion, having a lot of code that knows about the IOC container is an antipattern that increases complexity. I saw quite a bit of code in which objects can request an IOC container for their dependencies, and then they basically reduced the IOC container to a high-performance service locator.

Since IOC containers can resolve dependencies with an arbitrary degree of depth, it is quite easy to make the factory controller the component responsible for enabling inverse control containers. The constructor for each controller essentially defines the services / repositories / gateways that it needs.

For any of my applications, replacing the IOC container will essentially consist of rewriting the code that configures the container (indicates bindings, etc.) and connects the factory controller. For applications that are open as services, the same basic idea should be reasonably manageable, although depending on the limitations of your runtime, you might need to use installer injection rather than constructor injection.