Is learning Dependency Injection worth it for someone that usually only does small projects(5-20k lines)?

Question

I just usually do applications for myself as a hobby. It looks like DI frameworks have a big momentum in the community, so I thought maybe I should learn it to improve my coding skills. From what I understand, it seems to be geared more towards big projects. Is it still a good idea to use it for example in a 5k lines project?

Thanks

Answer 1

Yes - dependency injection promotes loose coupling and testability which is useful for a project of any size, and the overhead of configuration is relatively small.

Answer 2

I use DI for all code I write, no matter the size.

However, you should be aware that DI does not require a DI Container. A DI Container certainly helps (especially on big projects), but you can also write container-agnostic code using DI principles.

The size of the code base doesn't really matter. What matters is maintainability. DI enables loose coupling that again enables maintainability. For all but one-off, throw-away projects, that's valuable.

Answer 3

Effectively, dependency injection (DI) introduces some "complexity overhead" (as well as a relatively small size overhead), which may not seem worth the effort with smaller projects. However there are many direct, and indirect benefits to being familiar with DI, and to use it when appropriate. In particular:

More directly

• It makes for loose coupling of the components/modules within the project. Hence promoting reuse of code and patterns (from previous projects)
• It helps with testing by making it easier to introduce classes/modules which replace (mock) the real dependent types.

Indirectly

• It promotes the use of Interfaces: One defines the various parameters to API methods in terms of interfaces (or abstract classes) rather than concrete types.

As a result, you may find that even when not using DI in a given project or in parts thereof, familiarity with DI and its related concepts and patterns helps structuring the project with more abstractions, fewer "hard" dependency points and generally clearer, more self-documenting, object models.

Answer 4

If you're not using dependency injection, than it's almost certain that you're not using a mocking framework for your unit tests, or perhaps not doing unit testing at all. One of the nice things about unit testing is that, eventually, it will drive you to use better design patterns, including dependency injection. If you don't you'll find it very hard to test your code.

Whether or not learning how to use DI framework is necessary for applications of your size is an open question. Adding any external code to your project will add some complication and, honestly, I haven't found it compelling enough for my projects -- yet. At the same time, though, at one point I was creating all my mock object by hand and, since switching to RhinoMocks, I rarely hand mock objects and I feel that my productivity has improved. DI containers are the next technology on my list of things to explore, but I haven't round a project to try it out on yet.

My suggestion, since you seem to be open to it, would be to try a couple of DI frameworks and see how well they work for you. If you don't find enough value, then try doing manual injection -- assuming you're not at this point, if you are, then go back to it.

Answer 5

Yes, assuming you would be happy turning your 5k to 20k line projects into 3k to 10k line projects.

Yes, assuming you would like to write less test code while testing a larger portion of your code base.

Yes, assuming you would like to evaluate if DI would help you be a better programmer.