3

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?

lysergic-acid
  • 19,570
  • 21
  • 109
  • 218

3 Answers3

3

Quoting Mark Seemann:

Applications should depend on containers. Frameworks should not.

Community
  • 1
  • 1
TrueWill
  • 25,132
  • 10
  • 101
  • 150
1

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.

Jonas Høgh
  • 10,358
  • 1
  • 26
  • 46
1

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.

Mark W
  • 3,879
  • 2
  • 37
  • 53
  • 3
    Though I like your answer, I'm hesitant to upvote any answer like "X is {never/always} Y." – Austin Salonen Dec 09 '11 at 23:05
  • My question is -- what benefits will i gain by using such a framework? As for why not use it -- deployment issues (more files to deploy, maybe more platforms needed to be managed if it's 64 or 32bit), learning curve (although not a steep one), may cause confusion to the end user (how to configure?) if the configuration is not like the standard simple .NET config file, etc. – lysergic-acid Dec 09 '11 at 23:08
  • 2
    @Mark W - There is always a cost to taking a dependency to a 3rd party library, in the form of added complexity, steeper learning curve for new developers, etc. Also, you don't have to violate the Dependency Inversion Principle just because you aren't using an IoC container. If your code is cleanly structured, adding a container later on should be quite painless. – Jonas Høgh Dec 09 '11 at 23:11
  • Jonas, you're right, you can do DI all day without an IoC. But if you're going to do that why not use one of these tools that at best take an hour of reading to understand and implement. Out of all of the nifty things you can do in dev, IoC took me the least amount of time to understand. Design Patterns, mocking, stubbing, are on a different level. If the dev already understands what an Interface is and that you should inject these into your classes, an IoC container is pretty easy to understand. It sounds like he knows what an IoC container does and what DI is already. Might as well use – Mark W Dec 09 '11 at 23:38
  • Regardless, as you mentioned, as long as DI is being done the app can be refactored out to an IoC container (which usually happens at some point anyway) so write the few lines that do it now, then wait until you realize you need to use one. Also you mentioned using an app.config, most if not every IoC container out there will let you use the app.config to wire up your interfaces to classes. – Mark W Dec 09 '11 at 23:41