Вы можете спроектировать ваши классы так, чтобы их зависимости вводились (через конструктор или свойства) без использования инфраструктуры внедрения зависимостей. Просто создайте экземпляр зависимости самостоятельно и передайте ее или извлеките из локатора службы или класса реестра, который вы бросаете вместе. Но вместо того, чтобы сам класс разрешал свои зависимости, вызывая локатор службы, пусть класс, который создает экземпляр класса, разрешает для него зависимости. Вы поддерживаете тестируемый дизайн класса без дополнительных затрат и сложности другой библиотеки и фреймворка.
Я, например, знаю, что всякий раз, когда я пытался использовать DI-фреймворк, это, по сути, все, для чего я в итоге использовал его. Я также видел случаи, когда люди помещали свои DI-контейнеры в статический класс IoC, чтобы создавать объекты на более низком уровне иерархии, и, на мой взгляд, такого рода поражение цели; разве это не вернулось к тому, чтобы быть сервис-локатором в тот момент? Я думаю, я не совсем понимаю разницу в практическом использовании. Я говорю, махинации, вы используете рефлексию и делаете большой стартовый удар, чтобы сделать то же самое.
Вы не можете устранить зависимости, но вы наверняка сможете скрыть их в файле конфигурации XML. В какой-то момент что-то будет называть new. Вы действительно собираетесь поменять реализацию интерфейса без перекомпиляции или повторного тестирования приложения? Если нет, то будь проще. Приятно нажать «Найти определение» и увидеть, что что-то действительно создается в классе локатора службы с явным синглтоном или ThreadStatic или некоторым другим поведением.
Просто мои два цента - я все еще довольно новичок в DI-фреймворках, но это мой текущий ход мыслей: инверсия управления полезна, но сами фреймворки, вероятно, только для очень больших проектов.