Using a dependency injection framework or write your own?

Question

When starting out with a new application, would you rather just use an existing dependency framework and risk the possible shortcomings, or would you opt to write your own which is completely adaptable and why?

Answer 1

IMO, our job is to solve our client's problems, not write dependency injection (or logging, or ORM, etc) frameworks. When a suitable framework exists, in my opinion, you should always use that framework.

To add to this, if that framework is open source, then there is no excuse not to use it as you can fix any possible shortcomings.

I think that too often we lose site of our objectives. As programmers, we tend to focus on the interesting problems (writing a dependency injection framework for example) and procrastinate on the boring problems (writing yet another CRUD application for a client.) :D

Answer 2

I think the DI frameworks that are out there now are pretty solid (at least for .Net)...why take all that time to re-invent the wheel?

Answer 3

I would of course use one of the available solutions. Although it starts out simple, there are some features (like various proxying features) that are definitely not simple in full featured DI frameworks. Maybe you want some AOP too ?

But any decent DI framework should have little impact on the way you write your actual code, so it is possible to argue that it doesn't matter that much for your code.

It may matter for whoever's paying though. In your situation I'd get a DI framework with source code available, and get to know that source instead of writing your own.

Answer 4

Initially it may not seem like a big task to do a DI framework, but if you take a look at what frameworks such as Castle and Spring.NET offer, I can think of better ways to spend the time. Unless you need something really special, I would adopt one of the available frameworks and leverage the work of others.

Answer 5

Option 3: Do not use dependency injection (yet).

You're just starting a new project. Do you really need a DI framework yet?

Start developing the project, and you might start to see some problematic dependencies. Once they begin to emerge, you can evaluate the existing DI frameworks and decide which ones are appropriate.

Who knows, you might just discover that you don't need a DI framework at all.

Even Martin Fowler says:

Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

http://martinfowler.com/articles/injection.html

If I were you, I'd avoid using any dependency injection until you absolutely can't get by without it.

Remember, in most cases, YAGNI.

Answer 6

The DI frameworks are evolving all the time, and they additional functionality too, for example to make your code easier to test. Writing your own will be more error-prone and propably more complex when the project grows.

I'd say use them if you need DI and choose one that has good support.

Answer 7

You can write a wrapper around the dependency injection bits so if you want to switch DI frameworks later, you don't need to worry about library dependencies or changing code anywhere. For example, instead of directly calling container.Resolve, write a factory class that calls container.Resolve for you, and only call into the factory class.