Is an IoC container an overkill for a very simple framework

Question

I am creating a library that integrates our product with another 3rd party product.

The design being used involves an interface that abstracts the core operations i'd like to integrate to our product, such that when a new 3rd party API is released, we would transparently switch to using it instead of the old one without modifying existing code.

To this end, the actual code that will return a concrete instance of the object interacting with 3rd party API needs to make a decision on to "which implementation to select".

For the simple needs, i assume an entry in the configuration file would suffice to say the fully qualified implementing class name.

Should i use an IoC container in this case, or should i use a Factory Method pattern and code it myself? (use reflection to instantiate the object, etc).

What are the pros and cons for this? Am i missing anything?

Answer 1

Quoting Mark Seemann:

Applications should depend on containers. Frameworks should not.

Answer 2

Any IoC container is never overkill. You WILL eventually expand on this app if it's successful, or at the least used regularly and you will get requests to add more.

I'm a Castle user, and it's darn easy to add Castle with NuGet then just create a new WindsorContainer() in the startup and register your interfaces and class.

It's like asking if TDD is overkill to make a simple app. You should always (if you can) TDD the app, and use interfaces over concrete in your classes. IoC is too easy to setup now that you're only adding a few lines of code, so why not? it will be much harder later on if you didn't originally use an IoC container and you have intefaces and newed up classes all over your project to organize them all back into an IoC container.

Answer 3

An IoC container sounds like overkill for your problem. If you have only one dependency to inject, doing it via the config file should be just fine.