Проще говоря, когда вы хотите слабую связь между классами.
Я думаю, что Марк Симанн в своей книге Внедрение зависимостей в .NET имеет простое, но очень верное утверждение о DI / IoC:
DI обеспечивает слабую связь, а слабая связь делает код более понятным.
Таким образом, вы должны использовать его, когда хотите получить все преимущества, которые дает слабая связь, и это лишь некоторые из книг: позднее связывание, расширяемость, возможности параллельной разработки, тестируемость. За все эти преимущества вы оплачиваете стоимость внедрения и поддержки IoC-решения в вашей кодовой базе, что для проектов в области «зеленых полей», по-моему, незначительно, особенно благодаря контейнерам IoC. Для идей о том, как реализовать его глобально для вашего приложения, вы можете взглянуть на Composition Root Pattern .
Конечно, также возможно реализовать IoC только для частей вашего проекта, особенно если вы работаете с проектом коричневого поля. Однако если вы используете контейнер IoC, то одним из недостатков этого подхода является то, что использование контейнера IoC может перестать быть прозрачным, но вы должны явно вызвать его и запросить нужные вам экземпляры (шаблон локатора служб).