Здравствуйте, takTak, Вы писали: T>все разговоры в этой теме от банального непонимания, для чего придумали DI / IoC
Это верно.
А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers.
Вот тут очень хорошее объяснение для кого это нужно и как использовать.
Но это многе не понимают, и даже когда пишут микросервис из 5 классов, втыкают туда контейнер, "ибо надо". Но объяснить для чего — не могут. T>ну так вот тебе надо ПРОТЕСТИРОВАТЬ, что схема базы данных, используемая твоим кодом, актуальна, например,
А ещё многие не понимают разницу между выделением интерфейсов, IoC, DI, контейнерами. T>как ты с твоим этим кодом будешь писать код, который это проверяет?
var mainService = new MainService(new InMemoryProvider());
...
testThis(mainService);
testThat(mainService);
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
МП>>>кто-то может популярно расписать преимущества либо природу явления популярности? МП>>>(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
T>>покажи просто, как ты собираешься поддерживать систему, над которой работали и 10 лет назад (и все эти люди уже уволились) и позавчера пара практикантов, а сегодня надо приделать какую-то фичу тебе и ты эту систему увидел в первый раз
TG>Встречный закономерный вопрос: как в этом случае поможет DI? TG>И можно пример кода, пожалуйста.
система при DI делится на кучу заменямых компонентов, так что сделанные изменения проще тестировать,
если все прошлые изменения покрыты тестами (а когда есть DI, это сделать в разы проще), то прогонка этих же регрессионных тестов может указать на явные ошибки, когда ни тестов ни нет, то поддержка по становится чем-то вроде ходьбы по канату на высоте 100 метров без страховки
применимо это к так называемым оо — системам, при фунциональщине тесты базируются на иной парадигме, там композиция делается по-другому
T>>все разговоры в этой теме от банального непонимания, для чего придумали DI / IoC ·>Это верно. ·>А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers.
о чём ты вообще? идея юнит-тестирования намного старше веб-серверов... ·>Но это многе не понимают, и даже когда пишут микросервис из 5 классов, втыкают туда контейнер, "ибо надо". Но объяснить для чего — не могут.
T>>ну так вот тебе надо ПРОТЕСТИРОВАТЬ, что схема базы данных, используемая твоим кодом, актуальна, например, ·>А ещё многие не понимают разницу между выделением интерфейсов, IoC, DI, контейнерами.
T>>как ты с твоим этим кодом будешь писать код, который это проверяет? ·>
·>var mainService = new MainService(new InMemoryProvider(), new Configuration(), new IdentityProvider(Thread.Current.Identity), new FileManager() , new EmailSerice(new SmtrAddress(25.145.789), etc.));
·>...
·>testThis(mainService);
·>testThat(mainService);
·>
этот код показывает, что ты ни разу правильно не написал тестового кода с использованием DI, правильно было бы так:
·>
>Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
·>var mainService = Container.Resolve<MainService> ();
·>...
·>testThis(mainService);
·>testThat(mainService);
·>
Здравствуйте, takTak, Вы писали:
T>>>все разговоры в этой теме от банального непонимания, для чего придумали DI / IoC T>·>Это верно. T>·>А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers. T> о чём ты вообще? идея юнит-тестирования намного старше веб-серверов...
"веб-сервер" я не говорил, не приписывай мне ложные высказывания.
Для юнит-тестирования контейнер не нужен тоже, чаще даже вреден. Нужен DI.
T>>>как ты с твоим этим кодом будешь писать код, который это проверяет?
T>·>var mainService = new MainService(new InMemoryProvider(), new Configuration(), new IdentityProvider(Thread.Current.Identity), new FileManager() , new EmailSerice(new SmtrAddress(25.145.789), etc.));
T>·>...
Ты предлагаешь посылать письма и писать файлы из тестов? Особенно весело бороться в тестах с многопоточкой. Нет, в тестахм добрая половина этих зависимостей будут тестовые реализации.
А для второй половины — если же ты хочешь потестировать интеграцию MainService с какими-то фиксированными зависимостями, которые так же используются и в реальном приложении тоже, просто делаешь классическую композицию и у тебя получается переиспользуемый модуль со своими зависимостями, например что-то типа такого:
class MainServiceModule
{
MainService service;
MainServiceModule(DbProvider dbProvider, EmailService emailService)
{
service = new MainService(dbProvider, configuration, new IdentityProvider(Thread.Current.Identity), new FileManager(), emailService);
}
}
T>этот код показывает, что ты ни разу правильно не написал тестового кода с использованием DI, правильно было бы так:
Такой код я писал, конечно. Но с тех пор кое-чему научился.
T>>Container.Register<InMemoryProvider, DbProvider> ()
Это не DI, это контейнер. Разберись в конце-концов что такое DI.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
T>>>>все разговоры в этой теме от банального непонимания, для чего придумали DI / IoC T>>·>Это верно. T>>·>А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers. T>> о чём ты вообще? идея юнит-тестирования намного старше веб-серверов... ·>"веб-сервер" я не говорил, не приписывай мне ложные высказывания.
ой, насмешил... твой сервер приложений ещё моложе, чем веб-сервера ·>Для юнит-тестирования контейнер не нужен тоже, чаще даже вреден. Нужен DI.
ну ка покажи, как ты собираешься делать DI без Ioc контейнера
T>>>>как ты с твоим этим кодом будешь писать код, который это проверяет? ·>
T>>·>var mainService = new MainService(new InMemoryProvider(), new Configuration(), new IdentityProvider(Thread.Current.Identity), new FileManager() , new EmailSerice(new SmtrAddress(25.145.789), etc.));
T>>·>...
·>
·>Ты предлагаешь посылать письма и писать файлы из тестов? Особенно весело бороться в тестах с многопоточкой. Нет, в тестахм добрая половина этих зависимостей будут тестовые реализации.
ты сам назвал сервис "Main", а теперь на меня обижаешься ? в том-то и дело, что в одном случае у тебя его в твоём тесте даже инициировать толком не получится, а в моём варианте инициализация и тестового и продуктивного кода выглядит почти одинаково, с одним лишь отличием, что я подменяю то, что тестирую и вызываю тем, что меня в тесте интересует
·>А для второй половины — если же ты хочешь потестировать интеграцию MainService с какими-то фиксированными зависимостями, которые так же используются и в реальном приложении тоже, просто делаешь классическую композицию и у тебя получается переиспользуемый модуль со своими зависимостями, например что-то типа такого: ·>
·>class MainServiceModule
·>{
·> MainService service;
·> MainServiceModule(DbProvider dbProvider, EmailService emailService)
·> {
·> service = new MainService(dbProvider, configuration, new IdentityProvider(Thread.Current.Identity), new FileManager(), emailService);
·> }
·>}
·>
ну это уже тонкости, как ты там назовёшь: модуль , сервис или ещё как...
T>>этот код показывает, что ты ни разу правильно не написал тестового кода с использованием DI, правильно было бы так: ·>Такой код я писал, конечно. Но с тех пор кое-чему научился.
T>>>Container.Register<InMemoryProvider, DbProvider> () ·>Это не DI, это контейнер. Разберись в конце-концов что такое DI.
так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим
Здравствуйте, Министр Промышленности, Вы писали:
МП>все аргументы которые ему нужны он попросит как входящие аргументы МП>причем эти все аргументы наверняка будут примитивными типами, типа строк и чисел
Это приведет к тому, что ты будешь передавать параметры, которые нужны нижестоящим сервисам, а также еще нижестоящим и т.п.
Таких параметров будет очень много (вся конфигурация приложения). А самое главное, при добавлении нового свойства конфигурации тебе придется менять конструкторы всех классов, которые "пропускают" через себя этот параметр. Аналогично при изменении какого-то компонента системы — если ты изменил реализацию (заменил БД на микросервис), то свойства станут другие, и опять же придется переделывать кучу кода по созданию объектов.
А в проектах с DI ты делаешь изменение в одном месте — в composition root.
МП>чтобы его вызвать нужно будет вначале явно задействовать логику по прочтению конфигурации/обращению к базе данных и т.п. для получения значений
Это вообще ужас. Мало того, что нужно передавать 100 параметров, так еще каждый раз когда мы вызываем этот хелпер, мы должны каким-то способом обратиться к БД.
Но для работы с БД, нам нужна connection string и прочие параметры БД. Откуда мы возьмем их? Опять вызовем хелпер, чтобы вызвать другой хелпер? В общем, получается лапша хелперов.
Чтобы убрать эту лапшу поступают просто — объекты делают глобальными (конфигурация, контекст БД и т.п.). И рано или поздно проявляются проблемы работы с глобальными переменными.
МП>по мне так это структура программы здорового человека МП>она будет явной, поддерживаемой и развиваемой
Имхо наоборот, DI позволяет разбить всю систему на абсолютно независимые блоки, а затем из небольших блоков иерархически собирать всё более крупные блоки. Позволяет легко создавать и тестировать блоки — они относительно небольшие и независимые, позволяет легко заменять и добавлять блоки. Позволяет гибко настраивать конфигурацию всего приложения и каждого блока в отдельности.
Именно эта независимость частей системы придает системе гибкость, и это же добавляет сложности. Просто с ней работать нужно немного иначе.
Здравствуйте, takTak, Вы писали:
T>>>·>А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers. T>>> о чём ты вообще? идея юнит-тестирования намного старше веб-серверов... T>·>"веб-сервер" я не говорил, не приписывай мне ложные высказывания. T>ой, насмешил... твой сервер приложений ещё моложе, чем веб-сервера
Ага, и причём тут идея юнит-тестирования? Ты споришь с сам с собой. Я тебе не мешаю?
T>·>Для юнит-тестирования контейнер не нужен тоже, чаще даже вреден. Нужен DI. T>ну ка покажи, как ты собираешься делать DI без Ioc контейнера Тут уже раз сто показывали. Вот ещё раз.
T>·>Ты предлагаешь посылать письма и писать файлы из тестов? Особенно весело бороться в тестах с многопоточкой. Нет, в тестахм добрая половина этих зависимостей будут тестовые реализации. T>ты сам назвал сервис "Main", а теперь на меня обижаешься ?
У тебя опять проблемы с чтением. Сервис так не я назвал, а varenikAA тут
.
T>в том-то и дело, что в одном случае у тебя его в твоём тесте даже инициировать толком не получится,
У тебя не получится, у других получится. Если не будешь отключать мозг, то и ты научишься, это не сложно.
T>а в моём варианте инициализация и тестового и продуктивного кода выглядит почти одинаково, с одним лишь отличием, что я подменяю то, что тестирую и вызываю тем, что меня в тесте интересует
А в моём варианте инициализация будет вызывать тот же самый код.
T>ну это уже тонкости, как ты там назовёшь: модуль , сервис или ещё как...
Ну да, суть в том, что код для композиции нескольких компонент — это тоже самый обыкновенный код, а не контейнерная магия.
T>>>>Container.Register<InMemoryProvider, DbProvider> () T>·>Это не DI, это контейнер. Разберись в конце-концов что такое DI. T>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим
Я уже написал тут
T>>>>·>А придумали контейнеры для сборки монструозных монолитных enterprise приложений из крупных отдельно поставляемых компонент, плагинной архитектуры, внутри так называемых application servers. T>>>> о чём ты вообще? идея юнит-тестирования намного старше веб-серверов... T>>·>"веб-сервер" я не говорил, не приписывай мне ложные высказывания. T>>ой, насмешил... твой сервер приложений ещё моложе, чем веб-сервера ·>Ага, и причём тут идея юнит-тестирования? Ты споришь с сам с собой. Я тебе не мешаю?
итак, возвращаемся к первому предложению: юнит-тестирование возникло до появления серверов приложений, так что облегчающие юнит-тесторование DI не имеет к серверам приложений никакого отношения
T>>·>Для юнит-тестирования контейнер не нужен тоже, чаще даже вреден. Нужен DI. T>>ну ка покажи, как ты собираешься делать DI без Ioc контейнера ·> Тут уже раз сто показывали. Вот ещё раз.
ты на своём коде покажи, "а вот дядя знает" в другом возрасте употребляют
T>>·>Ты предлагаешь посылать письма и писать файлы из тестов? Особенно весело бороться в тестах с многопоточкой. Нет, в тестахм добрая половина этих зависимостей будут тестовые реализации. T>>ты сам назвал сервис "Main", а теперь на меня обижаешься ? ·>У тебя опять проблемы с чтением. Сервис так не я назвал, а varenikAA тут
.
пиши в спортлото
T>>в том-то и дело, что в одном случае у тебя его в твоём тесте даже инициировать толком не получится, ·>У тебя не получится, у других получится. Если не будешь отключать мозг, то и ты научишься, это не сложно.
не спорю, в этом ты- мастак
T>>а в моём варианте инициализация и тестового и продуктивного кода выглядит почти одинаково, с одним лишь отличием, что я подменяю то, что тестирую и вызываю тем, что меня в тесте интересует ·>А в моём варианте инициализация будет вызывать тот же самый код.
так ты точно уверен, что ты не сам с собой общаешься ?
T>>ну это уже тонкости, как ты там назовёшь: модуль , сервис или ещё как... ·>Ну да, суть в том, что код для композиции нескольких компонент — это тоже самый обыкновенный код, а не контейнерная магия.
T>>>>>Container.Register<InMemoryProvider, DbProvider> () T>>·>Это не DI, это контейнер. Разберись в конце-концов что такое DI. T>>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим ·>Я уже написал тут
Здравствуйте, takTak, Вы писали:
T>·>Ага, и причём тут идея юнит-тестирования? Ты споришь с сам с собой. Я тебе не мешаю? T>итак, возвращаемся к первому предложению: юнит-тестирование возникло до появления серверов приложений, так что облегчающие юнит-тесторование DI не имеет к серверам приложений никакого отношения
Да. И? Я ничего другого и не утверждал. Ты просто путаешь DI и DI-контейнеры. А вот контейнеры и фреймворки имеют прямое отношение к серверам приложений ибо идея пошла оттуда.
T>>>ну ка покажи, как ты собираешься делать DI без Ioc контейнера T>·> Тут уже раз сто показывали. Вот ещё раз. T>ты на своём коде покажи, "а вот дядя знает" в другом возрасте употребляют
Ещё раз: вот тут
ванильный DI, без контейнеров и интерфейсы тоже не обязательны.
T>>>ты сам назвал сервис "Main", а теперь на меня обижаешься ? T>·>У тебя опять проблемы с чтением. Сервис так не я назвал, а varenikAA тут
. T>пиши в спортлото
Действительно, тебе писать бесполезно, ты всё равно не читаешь, только хамишь.
T>>>в том-то и дело, что в одном случае у тебя его в твоём тесте даже инициировать толком не получится, T>·>У тебя не получится, у других получится. Если не будешь отключать мозг, то и ты научишься, это не сложно. T>не спорю, в этом ты- мастак
Да, спасибо. И тебе того же желаю.
T>·>А в моём варианте инициализация будет вызывать тот же самый код. T>так ты точно уверен, что ты не сам с собой общаешься ?
Да, уверен, просто ты не слушаешь.
T>>>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим T>·>Я уже написал тут
и выше. Если кода мало и он примитивный это не означает, что он какой-то неправильный, тебе просто непривычно после контейнеров-то. T>т.е. ты делаешь DI без интерфейсов? ты точно свою ссылку из википедии прочитал?
Да, прочитал. Для DI/CI интерфейсы не нужны. И контейнеры тоже. А интерфейсы _нужны_ только для так называемого частного случая Interface Injection (который в этом обсуждении ни разу не упоминался). И ты прочитай, рекомендую.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Б>> "Pure DI" vs "DI Container".
S>А в чем отличие?
в одном случае ты всё делаешь сам на своих коленках и с использованием своего велосипеда, который никому, кроме тебя, неинтересен,
в другом случае (опять же, никаких "DI container" нет, есть "IoC container" ) ты пользуешься трудом тех, кто до тебя на сотню-другую граблей уже наступил
Здравствуйте, Sharov, Вы писали:
S>А в чем отличие?
DI можно использовать и без DI-контейнера. Весь код по созданию объектов пишется вручную — как классы с методами createAnything (в Main или в какой-то подсистеме).
Из плюсов — явный вызов всех конструкторов. Удобно описываются взаимосвязи, а также все связи контролируются компилятором (для статических языков).
Это как раз тот случай, когда и DI используется, и все взаимосвязи указаны явно (как хочет топик-стартер) — можно использовать Find Usage и прочие штуки.
Из минусов — больше wiring-кода, сложнее управлять сроком жизни объектов. Чуть менее удобно переопределять зависимости для тестирования — приходится создавать наследника для переопределения методов.
Здравствуйте, varenikAA, Вы писали:
AA>>>>>Понял, а то у ТС вообще неопнятно на что он жалуется. ну это субъективно. так то во всех учебниках учат что надо избегать явного создания объектов. IT>>>>Они не учат почему этого нужно избегать? Если нет, то ввыкинь такие учебники на помоечку. Впрочем, если да, то тоже выкинь. AA>>>Чтобы не зависеть от реализации. IT>>Зачем? Какую проблему это решает? AA>Например, командная разработка. Интерфейсы согласованы и лежат в общей сборке. Один работает над клиентом, другой над реализацией интерфейса.
А проблема в чём? Зачем тут интерфейсы? К тому же, насколько мне известно, командная разработка это больше об SMS, чем об интерфейсах.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Буравчик, Вы писали:
S>>А в чем отличие? Б>Из минусов — больше wiring-кода,
Это как правило неправда. В лучшем случае кода будет примерно столько же. А чаще кода будет меньше, т.к. теперь не надо описывать тот же wiring-код в виде api данного контейнера — всякие там аннотации, специальные интерфейсы, конфиги, регистрация компонент и т.п.
Кода меньше может быть если использовать неявную регистрацию компонентов, что в больших проектах очень не рекомендуется. А в простых проектах это будет экономия на спичках.
Б> сложнее управлять сроком жизни объектов.
Это тоже не совсем правда. Тут ещё одна путаница. Тут уже путаются понятия "IoC-контейнер" и фреймворк. Контейнер это просто свалка инстансов, мапа просто {тип -> объект}. А фреймворк это уже целая интегрированная библиотека с кучей готовых тулзов. Например, AOP, lifecycle (start/stop/Disposable), context events и т.п.
Ещё могут быть готовые к использованию чтение конфигов, scopes, маппинги для http и т.п. И это уже всё к IoC не относится.
Б> Чуть менее удобно переопределять зависимости для тестирования — приходится создавать наследника для переопределения методов.
Это ерунда какая-то, к DI прямого отношения не имеет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, C0s, Вы писали:
C0s>с одной стороны, если мы говорим о поломанных объектах, то при правильном программировании инвариантов их возможное существование будет пресекаться на корню. либо в конструкторе, либо в фабрике/билдере. и это безотносительно DI, а просто как правило хорошего тона и clean code.
Да, да. Особенно в сферическом вакууме или на примитивных проектах, типа PetShop.
C0s>к чему это я (ответ всем тем, кто отметился в этой подветке): не надо сравнивать DI или не-DI там, где проблемы возникают по другим причинам.
Никто и не сравнивает DI или не-DI. Сравнивают DI фреймворк или не-DI фреймворк.
C0s>- пользоваться дебаггером для этого — моветон. нужно учиться логировать и читать логи. в первую очередь из-за того, что, когда проблема прилетает из продуктива, никакой дебаггер не поможет, а логи — да.
У меня процессы работают всю ночь. Если логировать каждую строчку кода в подробностях и с прилежанием, то место на диске с логами закончится очень быстро. А так да, логируем, куда девваться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Да, да. Особенно в сферическом вакууме или на примитивных проектах, типа PetShop.
правила хорошего тона и clean code не зависят от размера проекта, и полезны сразу и систематически — до того, как проект начнёт внезапно разрастаться. более того, обычный подготовленный специалист это делает на автомате без дополнительных трудозатрат. а наличие неподготовленного — сам понимаешь, вроде и реальность, но является лишь организационной проблемой, а не инженерной.
C0s>>к чему это я (ответ всем тем, кто отметился в этой подветке): не надо сравнивать DI или не-DI там, где проблемы возникают по другим причинам.
IT>Никто и не сравнивает DI или не-DI. Сравнивают DI фреймворк или не-DI фреймворк.
раз уж мы тут, то DI-фреймворк важен тем, что для правильного применения сразу требует хорошего чувства объектного построения, проектирования надёжных и устойчивых моделей, а также инверсии зависимостей. без оного этого тоже можно добиться, но только палкой или кнутом. кроме того, фреймворки типа spring являются сами по себе примерами хорошего кода, содержат массу готовых велосипедов с гибкой настройкой нужных скоростей на любые направления движения.
IT>У меня процессы работают всю ночь. Если логировать каждую строчку кода в подробностях и с прилежанием, то место на диске с логами закончится очень быстро. А так да, логируем, куда девваться.
не надо логировать постоянно, достаточно возможности увеличивать или уменьшать подробность логирования без останова процесса. нашли проблему пользователи — включаем логи, просим повторить, снимаем их и анализируем.
T>>·>Ага, и причём тут идея юнит-тестирования? Ты споришь с сам с собой. Я тебе не мешаю? T>>итак, возвращаемся к первому предложению: юнит-тестирование возникло до появления серверов приложений, так что облегчающие юнит-тесторование DI не имеет к серверам приложений никакого отношения ·>Да. И? Я ничего другого и не утверждал. Ты просто путаешь DI и DI-контейнеры.
просто я никогда не пользовался никакими серверами приложений: контейнеры были для меня именно помощью в написании проложений, так чтобы получебнное прлижение просто тестировалось бы,
если же тестов не предвидится, то и никакого смысла в том, чтобы композицию обьектов прозводить через DI, я не вижу, тут я на стороне того, кто эту ветку начал
ты начал использовать DI в контексте серверов приложений, причём, наверное, и без всяких тестов, имхо такой способ композиции приложения довольно прост, но какого-то выиграша от такого подхода , на самом деле, не видно
·>А вот контейнеры и фреймворки имеют прямое отношение к серверам приложений ибо идея пошла оттуда.
я тебе уже в который раз повторяю, что идея пошла от юнит-тестирования, вероятно, создатели серверов приложений были в курсе того, что необходимо предложить пользователям возможность юнит-тестирования, и оно тут в списке первично
T>>>>ну ка покажи, как ты собираешься делать DI без Ioc контейнера T>>·> Тут уже раз сто показывали. Вот ещё раз. T>>ты на своём коде покажи, "а вот дядя знает" в другом возрасте употребляют ·>Ещё раз: вот тут
ванильный DI, без контейнеров и интерфейсы тоже не обязательны.
то, что ты называешь "ванильным" , создаёт жёсткие зависимости между компонентами, что делает практически невозможным изолированное тестирование
T>>·>А в моём варианте инициализация будет вызывать тот же самый код. T>>так ты точно уверен, что ты не сам с собой общаешься ? ·>Да, уверен, просто ты не слушаешь.
ты первый начал
T>>>>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим T>>·>Я уже написал тут
и выше. Если кода мало и он примитивный это не означает, что он какой-то неправильный, тебе просто непривычно после контейнеров-то. T>>т.е. ты делаешь DI без интерфейсов? ты точно свою ссылку из википедии прочитал? ·>Да, прочитал. Для DI/CI интерфейсы не нужны. И контейнеры тоже. А интерфейсы _нужны_ только для так называемого частного случая Interface Injection (который в этом обсуждении ни разу не упоминался). И ты прочитай, рекомендую.
этот , как ты говоришь , "частный случай" — для меня единственно возможное и целесобразное применение , иначе смысла просто нет
Здравствуйте, Буравчик, Вы писали:
Б>Таких параметров будет очень много (вся конфигурация приложения). А самое главное, при добавлении нового свойства конфигурации тебе придется менять конструкторы всех классов, которые "пропускают" через себя этот параметр. Аналогично при изменении какого-то компонента системы — если ты изменил реализацию (заменил БД на микросервис), то свойства станут другие, и опять же придется переделывать кучу кода по созданию объектов.
Б>А в проектах с DI ты делаешь изменение в одном месте — в composition root.
Как часто в своей жизни ты заменял БД на микросервисы?
Б>Чтобы убрать эту лапшу поступают просто — объекты делают глобальными (конфигурация, контекст БД и т.п.). И рано или поздно проявляются проблемы работы с глобальными переменными.
У меня проекту уже лет семь. Года четыре в продакшине. Глобавльные сетинги имеются. Сколько мне ещё осталось ждать до проявления проблем?
Б>Именно эта независимость частей системы придает системе гибкость, и это же добавляет сложности. Просто с ней работать нужно немного иначе.
Вопрос. Зачем нужна такая гибкость? Какую проблему это решает?
Если нам не помогут, то мы тоже никого не пощадим.
о чём ты вообще? идея юнит-тестирования намного старше веб-серверов... 
Если нам не помогут, то мы тоже никого не пощадим.
