Should I avoid using Dependency Injection and IoC? : <p>In my mid-size project I used static classes for repositories, services etc. and it actually worked very well, even if the most of programmers will expect the opposite. My codebase was very compact, clean and easy to understand. Now I tried to rewrite everything and use <code>IoC</code> (Invertion of Control) and I was absolutely disappointed. I have to manually initialize dozen of dependencies in every class, controller etc., add more projects for interfaces and so on. I really don't see any benefits in my project and it seems that it causes more problems than solves. I found the following drawbacks in <code>IoC</code>/<code>DI</code>:</p>

<ul>
<li>much bigger codesize</li>
<li>ravioli-code instead of spaghetti-code</li>
<li>slower performance, need to initialize all dependencies in constructor even if the method I want to call has only one dependency</li>
<li>harder to understand when no IDE is used</li>
<li>some errors are pushed to run-time</li>
<li>adding additional dependency (DI framework itself)</li>
<li>new staff have to learn DI first in order to work with it</li>
<li>a lot of boilerplate code, which is bad for creative people (for example copy instances from constructor to properties...)</li>
</ul>

<p>We do not test the entire codebase, but only certain methods and use real database. So, should Dependency Injection be avoided when no mocking is required for testing?</p>
