IoC/DI for a small .NET projects

Question

The separation of concerns provided by IoC/DI frameworks cannot be overestimated for a large projects, but is there a place for such techniques in a small project?

Can you share some real-life uses of IoC/DI frameworks you found to be useful when you were coding another small/average project.

For the sake of definition:

A "small project" contains 100-1000 lines of code (balpark, just to give an idea), it takes a 1-3 days to code and the lifetime of the resulting application before it gets thrown away or decomissioned is within 1 week - 5 years after the initial release (this is there it gets hard to draw a line between small/average/large project).

Thanks.

Answer 1

For a small project, I'd be tempted to still use dependency injection, but not use a framework. Just craft all the dependencies in your entry point. You still get all the benefits of testability, and you can move on to use a fully-fledged container later on - but you don't need to worry about setting up the container until it's actually going to be useful.

I've used this approach on a couple of small projects, and it's worked very well. Of course, it depends on how complicated your dependencies are - whether they need to be factories, have different scoping etc - but if it's just "I have these three things which all depend on an authentication service" then that's pretty straightforward.

Answer 2

but is there a place for such techniques in a small project?

Even in small projects you should use the IoC pattern in order to weaken the coupling between the layers and make it unit testable. Always work with abstractions. Whether you use a DI framework or not doesn't really matter. In small projects you could simply do the plumbing of the dependencies manually, don't really need an object container to do the dependency injection, but when you give it a second thought why not?