hVosttАлексей Кпропущено...
DI может существовать и быть полезным без IoC, не так ли?

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html авторЧерез свойства должны устанавливаться лишь необязательные зависимости (обычно, инфраструктурные), для которых существует значение по умолчанию (свойство Logger содержит разумное значение по умолчанию, но может быть заменено позднее). Автор забыл сказать о том, что через свойства устанавливаются циклические зависимости, в том числе и обязательные.

hVosttАлексей КНиже пример из жизни, чего можно избежать при использовании ди-контейнера:

В твоём коде всё понятно, что откуда берётся, когда создаётся, ты привёл самый обычный фабричный метод.Которого могло не быть, если бы использовался диконтейнер.
hVosttЕсть говорить о контексте применения, то как раз инсталлятор должен конфигурироваться централизовано. Не самый удачный пример в подтверждение твоих мыслей.Данный проект не столь масштабен, чтобы использовать диконтейнер, поэтому он не использован. Но пример показателен.

hVosttАлексей К1. Области времени жизни.
2. Централизованное конфигурирование создания объектов.
3. Компактность кода.

1. Есть и обратная сторона, когда у тебя контекст времени жизни ясен и очевиден это одно. Другое, когда время жизни зависит от объекта, который использует зависимость. Один берёт попользоваться, другой хочет забрать себе и отдать тогда, когда сам решит. Лишь в теории и на студенческих примерах всё круто. И да, очень часто злоупотребление DI приводит к утечкам памяти или к нерациональной утилизации ресурсов.Нет. Области оберегают от утечек ресурсов. В том числе для этого они и придуманы.

hVostt2. Бутстраперы это хорошо, но знаешь в чём подвох? Когда-нибудь программисту надоедать регистрировать всё вручную. Это обязательно наступит рано или поздно. И тогда он захочет автоматическую регистрацию всех компонентов с помощью атрибутов. И вот тогда свой пункт 2 можешь смело вычеркнуть, как не имеющий отношения к реальности.Кроме атрибутов ещё бывают соглашения, которые отлично работают в прикладном коде.

hVostt3. Создание дополнительного уровня косвенности никогда не приводит к компактности кода. Наоборот. Просто ты переносишь создание из одного места в другое. Проблему создания объектов решает не только DI, есть другие способы. К слову.Какие ещё "косвенности"? Тупо экономим на фабричных методах и присваиваниях свойств или вызовах конструкторов. Пример приведён выше.

hVosttЕсли тебя я правильно понял. То ты пропагандируешь идёю: в топку остальные решения, только DI? Я никогда ничего не пропагандирую. Просто ты в очередной раз удивляешь своим идеализмом.

hVosttВот как раз я против идеализма, если ты не заметил.Я вот что заметил:hVosttЖелательно обходиться без DI там где это можно — максимально. Если что-то делается только внутри одного модуля и не выходит наружу, то в таких случаях лучше вообще избегать использования контейнера.Knockout плохой, Bootstrap ещё хуже, DI можно использовать только для модульности. Я ничего не забыл?

hVosttАтрибуты это ещё куда ни шло, но соглашения это ещё более слабое правило.Соглашения в EF code-first тобой любимы, а здесь нет. Что за двойные стандарты?


hVosttПойди найди потом правильную имплементацию зависимости. Скажи, а зачем вообще тогда зависимости? Почему бы не получать имплементацию с помощью поиска класса по имени и активацию его через рефлешкен? По сути, разницы нет.Давай напишем свою реализацию ID-контейнера? Готовые решения нас не устраивают?