T>>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим

IT>Похоже ты реально путаешь DI и контейнеры.


я не вижу никакого смысла в DI без IoC контейнерa, это тоже самое, что если есть буква, но "слов ещё не завезли"

Здравствуйте, C0s, Вы писали:

C0s>правила хорошего тона и clean code не зависят от размера проекта, и полезны сразу и систематически — до того, как проект начнёт внезапно разрастаться. более того, обычный подготовленный специалист это делает на автомате без дополнительных трудозатрат. а наличие неподготовленного — сам понимаешь, вроде и реальность, но является лишь организационной проблемой, а не инженерной.

У нас с тобой разные правила хорошего тона. Для тебя это непременное наличие какого-нибудь контейнера в проекте. Для меня — легко читаемый, легко изменяемый и легко остающийся легко изменяемым после изменений код.

IT>>Никто и не сравнивает DI или не-DI. Сравнивают DI фреймворк или не-DI фреймворк.
C0s>раз уж мы тут, то DI-фреймворк важен тем, что для правильного применения сразу требует хорошего чувства объектного построения, проектирования надёжных и устойчивых моделей, а также инверсии зависимостей. без оного этого тоже можно добиться, но только палкой или кнутом. кроме того,

Ты ещё забыл про сферический конь в вакууме. Это тоже важно для правильного применения хорошего чувства объектного построения. В обычной жизни, особенно в кговавом энтегпгайзе все кони настоящие и быстро превращают вьюношей бледных со взором горящим либо в настоящих мужчин, либо в конченных догматиков с исковерканной DI судьбой.

C0s>не надо логировать постоянно, достаточно возможности увеличивать или уменьшать подробность логирования без останова процесса. нашли проблему пользователи — включаем логи, просим повторить, снимаем их и анализируем.

Кто тебе сказал, что оно опять повторится?

Здравствуйте, takTak, Вы писали:

T>·>Да. И? Я ничего другого и не утверждал. Ты просто путаешь DI и DI-контейнеры.
T>просто я никогда не пользовался никакими серверами приложений: контейнеры были для меня именно помощью в написании проложений, так чтобы получебнное прлижение просто тестировалось бы,
T>если же тестов не предвидится, то и никакого смысла в том, чтобы композицию обьектов прозводить через DI, я не вижу, тут я на стороне того, кто эту ветку начал
Разберись в чём отличие DI и контейреров.
DI относится к юнит-тестированию — для инжекта моков.
Контейнеры относятся к апп-серверам. Там возникла идея "а давайте положим в контейнер транзакционные менеджеры, коннекты к базам, бины, и будем их извлекать и связывать автомагически".
Не мешай это всё в кучу.

T>ты начал использовать DI в контексте серверов приложений, причём, наверное, и без всяких тестов, имхо такой способ композиции приложения довольно прост, но какого-то выиграша от такого подхода , на самом деле, не видно
Видимо я просто не смог уследить за полётом твоей мысли, т.к. ты не понимаешь разницу между DI и контейнером. Вот тут ты пишешь одно, а строчкой ниже совсем другое.

этот код показывает, что ты ни разу правильно не написал тестового кода с использованием DI, правильно было бы так:
Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо

Мне надоело писать одно и то же. Ты игнорируешь эту разницу, тебя трудно понимать. Давай ты в следующем ответе опишешь своё понимание разницы DI и контейнеров, иначе смысла вести беседу я не вижу.

T>·>А вот контейнеры и фреймворки имеют прямое отношение к серверам приложений ибо идея пошла оттуда.
T>я тебе уже в который раз повторяю, что идея пошла от юнит-тестирования, вероятно, создатели серверов приложений были в курсе того, что необходимо предложить пользователям возможность юнит-тестирования, и оно тут в списке первично
У тебя ещё похоже путаница с пониманием видов тестов.
На минуточку задумайся — юнит-тестирование это тестирование маленьких юнитов, когда все зависимости юнита мокаются. Использование контейнера это уже будет относится к интеграционным тестам, когда тестируются сразу несколько юнитов, сынтегрированных в одно целое с помощью контейнера.
Так что к юнит-тестам имеет отношение DI, а не контейнеры.

T>>>ты на своём коде покажи, "а вот дядя знает" в другом возрасте употребляют
T>·>Ещё раз: вот тут

Автор: ·
Дата: 19.01.21

ванильный DI, без контейнеров и интерфейсы тоже не обязательны.
T>то, что ты называешь "ванильным" , создаёт жёсткие зависимости между компонентами,
Не создаёт.

T>что делает практически невозможным изолированное тестирование
Вот с контейнером обеспечить изолированное тестирование гораздо сложнее. Ибо вот ты написал

Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
var mainService = Container.Resolve<MainService> ();

У тебя Container может неявно втащить много чего и изолировать сложно.

T>·>Да, уверен, просто ты не слушаешь.
T>ты первый начал
Я слушаю, конечно, но ты мне ещё не рассказал ничего, что я не знаю.

T>>>т.е. ты делаешь DI без интерфейсов? ты точно свою ссылку из википедии прочитал?
T>·>Да, прочитал. Для DI/CI интерфейсы не нужны. И контейнеры тоже. А интерфейсы _нужны_ только для так называемого частного случая Interface Injection (который в этом обсуждении ни разу не упоминался). И ты прочитай, рекомендую.
T>этот , как ты говоришь , "частный случай" — для меня единственно возможное и целесобразное применение , иначе смысла просто нет
Ты издеваешься что-ли? Ты статью так и не прочитал. И нифига не понимаешь что такое Interface Injection.

Здравствуйте, takTak, Вы писали:

T>>>так давай, покажи написанный на твоёй коленке DI без контейнера, мы его оценим
IT>>Похоже ты реально путаешь DI и контейнеры.
T>я не вижу никакого смысла в DI без IoC контейнерa, это тоже самое, что если есть буква, но "слов ещё не завезли"

Я понял.

·>Контейнеры относятся к апп-серверам. Там возникла идея "а давайте положим в контейнер транзакционные менеджеры, коннекты к базам, бины, и будем их извлекать и связывать автомагически".
·>Не мешай это всё в кучу.
я тебе ещё раз говорю: ты со своей явой ни туда смотришь, контейнеров под дотнетом сотни, и никакими серверами приложений там даже близко не пахнет, как и в многих других языках

·>Мне надоело писать одно и то же. Ты игнорируешь эту разницу, тебя трудно понимать. Давай ты в следующем ответе опишешь своё понимание разницы DI и контейнеров, иначе смысла вести беседу я не вижу.
тебе твоя ява застилает глаза, контейнер не обязан быть сложным

T>>то, что ты называешь "ванильным" , создаёт жёсткие зависимости между компонентами,
·>Не создаёт.

T>>что делает практически невозможным изолированное тестирование
·>Вот с контейнером обеспечить изолированное тестирование гораздо сложнее. Ибо вот ты написал
·>

·>Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
·>var mainService = Container.Resolve<MainService> ();
·>

·>У тебя Container может неявно втащить много чего и изолировать сложно.
ну так я регистрирую то, что меня интересует, и разрешаю и использую только то, что меня в тесте интересует

T>>этот , как ты говоришь , "частный случай" — для меня единственно возможное и целесобразное применение , иначе смысла просто нет
·>Ты издеваешься что-ли? Ты статью так и не прочитал. И нифига не понимаешь что такое Interface Injection.
в моём мире существует разве что Constructor Injection/ Property Injection

Здравствуйте, ·, Вы писали:

Б>> Чуть менее удобно переопределять зависимости для тестирования — приходится создавать наследника для переопределения методов.
·>Это ерунда какая-то, к DI прямого отношения не имеет.

Задача в том, чтобы сделать интеграционный тест для некоторого сервиса.
1. Мы может собрать зависимости вручную, и собирая, сделать замену зависимостей на стабы/моки
2. Можем вытащить нужный сервис из composition root, но предварительно заменив некоторые зависимости в контейнере.

Я так понимаю, что ты предлагаешь первый вариант. Но второй вариант на мой взгляд лучше:
1. Это гарантирует, что сервис будет собран именно так, как в продакшене (кроме подмененных зависимостей)
2. Тесты будут требовать меньше изменений при изменении зависимостей.

В случае с контейнером, пишем что-то типа:

# production

cotainer = AppContainter()
app = container.create_app()
app.run()

# test code

cotainer = AppContainter()
service1 = Stub()
service2 = Mock()

container.override(dep1=service1, dep2=service2)

app = container.create_app()
app.run()

Чтобы реализовать переопределение зависимостей без использования контейнера создаем TestAppRoot (наследуется AppRoot), в котором переопределяем несколько create-методов.

# production

class AppRoot:
  method create_service1()
  method create_service2()
  method create_app()

app = AppRoot().create_app()
app.run()

# test code

class TestAppRoot(inherit AppRoot):
  method create_service1() - return Stub
  method create_service2() - return Mock

app = TestAppRoot().create_app()
app.run()

Здравствуйте, takTak, Вы писали:

T>·>Не мешай это всё в кучу.
T>я тебе ещё раз говорю: ты со своей явой ни туда смотришь, контейнеров под дотнетом сотни,
И большинство из них позаимствовано из Явы.

T> и никакими серверами приложений там даже близко не пахнет, как и в многих других языках
IIS же.

T>·>Мне надоело писать одно и то же. Ты игнорируешь эту разницу, тебя трудно понимать. Давай ты в следующем ответе опишешь своё понимание разницы DI и контейнеров, иначе смысла вести беседу я не вижу.
T>тебе твоя ява застилает глаза, контейнер не обязан быть сложным
Тебе твой дотнет застилает глаза, контейнер не обязан быть.

T>>>что делает практически невозможным изолированное тестирование
T>·>Вот с контейнером обеспечить изолированное тестирование гораздо сложнее. Ибо вот ты написал
T>·>

T>·>Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
T>·>var mainService = Container.Resolve<MainService> ();
T>·>

T>·>У тебя Container может неявно втащить много чего и изолировать сложно.
T>ну так я регистрирую то, что меня интересует, и разрешаю и использую только то, что меня в тесте интересует
Ты уж определись. Либо "мне трогать не надо", либо "регистрирую то, что меня интересует". Т.к. ты либо явно должен указать, что тебя интересует, либо это будет описано где-то неявно и тогда будет лезть что попадётся.

T>>>этот , как ты говоришь , "частный случай" — для меня единственно возможное и целесобразное применение , иначе смысла просто нет
T>·>Ты издеваешься что-ли? Ты статью так и не прочитал. И нифига не понимаешь что такое Interface Injection.
T>в моём мире существует разве что Constructor Injection/ Property Injection
И для них интерфейсы использовать не нужно (но можно, к DI это ортогонально). ЧТД.

T>>·>Не мешай это всё в кучу.
T>>я тебе ещё раз говорю: ты со своей явой ни туда смотришь, контейнеров под дотнетом сотни,
·>И большинство из них позаимствовано из Явы.

я даже не знаю, о чём ты.., ты , наверное, за словом "контейнер" понимаешь лишь j2ee container, ну так вот "контейнер" — это всего лишь "контейнер", не более, современные IoC контейнеры в отличных от явы языках очень легковесны

T>> и никакими серверами приложений там даже близко не пахнет, как и в многих других языках
·>IIS же.
это скорее веб север типа tomcat или apache

T>>·>Мне надоело писать одно и то же. Ты игнорируешь эту разницу, тебя трудно понимать. Давай ты в следующем ответе опишешь своё понимание разницы DI и контейнеров, иначе смысла вести беседу я не вижу.
T>>тебе твоя ява застилает глаза, контейнер не обязан быть сложным
·>Тебе твой дотнет застилает глаза, контейнер не обязан быть.
легковесный IoC контейнер безумно облегчает жизнь

T>>>>что делает практически невозможным изолированное тестирование
T>>·>Вот с контейнером обеспечить изолированное тестирование гораздо сложнее. Ибо вот ты написал
T>>·>

T>>·>Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
T>>·>var mainService = Container.Resolve<MainService> ();
T>>·>

T>>·>У тебя Container может неявно втащить много чего и изолировать сложно.
T>>ну так я регистрирую то, что меня интересует, и разрешаю и использую только то, что меня в тесте интересует
·>Ты уж определись. Либо "мне трогать не надо", либо "регистрирую то, что меня интересует". Т.к. ты либо явно должен указать, что тебя интересует, либо это будет описано где-то неявно и тогда будет лезть что попадётся.
так это тоже элементарно: если то, что по дефолту подтащится, для инициации теста прокатит, но в самом тесте вызвано не будет, то мне достаточно подменить только то, что я собираюсь тестировать

T>>>>этот , как ты говоришь , "частный случай" — для меня единственно возможное и целесобразное применение , иначе смысла просто нет
T>>·>Ты издеваешься что-ли? Ты статью так и не прочитал. И нифига не понимаешь что такое Interface Injection.
T>>в моём мире существует разве что Constructor Injection/ Property Injection
·>И для них интерфейсы использовать не нужно (но можно, к DI это ортогонально). ЧТД.

смысл использования интерфейса в оо — это double dispatch, и если у тебя имеется код, который десятилетиями не меняется, то и смылся ни в тестах ни в интерфейсе, ни в DI для него нет

Здравствуйте, Буравчик, Вы писали:

Б>Чтобы реализовать переопределение зависимостей без использования контейнера создаем TestAppRoot (наследуется AppRoot), в котором переопределяем несколько create-методов.
Б>

Б># production

Б>class AppRoot:
Б>  method create_service1()
Б>  method create_service2()
Б>  method create_app()
Б>

Ты почти дошел до цели, остался последний шаг. TestAppRoot не нужен! Теперь для AppRoot надо ТОЖЕ применить IoC и через DI заинжектить туда зависимости, которые ты хочешь подменять при интеграционном тестировании.
Т.е. main-метод реального приложения будет выглядеть так:

new AppRoot(new RealDb(), new RealFilesystem(), new SystemClock()...).run();

А для теста

new AppRoot(new MockDb(), new MockFilesystem(), new MockClock()...).run();

Другими словами, Composition Root это вовсе не одна большая простыня создания всего, а это тоже код, который тоже можно структурировать обычными способами. А значит части Composition Root так же можно переиспользовать в тестах и в прод-коде.

Здравствуйте, takTak, Вы писали:

T>>>я тебе ещё раз говорю: ты со своей явой ни туда смотришь, контейнеров под дотнетом сотни,
T>·>И большинство из них позаимствовано из Явы.
T>я даже не знаю, о чём ты.., ты , наверное, за словом "контейнер" понимаешь лишь j2ee container, ну так вот "контейнер" — это всего лишь "контейнер", не более, современные IoC контейнеры в отличных от явы языках очень легковесны
Раз не знаешь, так спрашивай, а не говори очередную глупость. В java полно контейнеров, всяко-весных. Из легковесных — pico, guice, dagger, например. Притом тому же pico лет 20 уже... современно! жив ли он? Не уверен.

T>>> и никакими серверами приложений там даже близко не пахнет, как и в многих других языках
T>·>IIS же.
T>это скорее веб север типа tomcat или apache
Тут терминология нечёткая, конечно. Но всё таки тот же kestrel далеко от iis.

T>>>тебе твоя ява застилает глаза, контейнер не обязан быть сложным
T>·>Тебе твой дотнет застилает глаза, контейнер не обязан быть.
T>легковесный IoC контейнер безумно облегчает жизнь
Пока не научишься код нормально писать.

T>·>Ты уж определись. Либо "мне трогать не надо", либо "регистрирую то, что меня интересует". Т.к. ты либо явно должен указать, что тебя интересует, либо это будет описано где-то неявно и тогда будет лезть что попадётся.
T>так это тоже элементарно: если то, что по дефолту подтащится, для инициации теста прокатит, но в самом тесте вызвано не будет, то мне достаточно подменить только то, что я собираюсь тестировать
Не понял. Если ты подменишь то, что собираешься тестировать, то ты будешь тестировать подмену.

T>·>И для них интерфейсы использовать не нужно (но можно, к DI это ортогонально). ЧТД.
T>смысл использования интерфейса в оо — это double dispatch,
Чё? Ты точно знаешь, что такое double dispatch? Или опять путаешь термины?

T>и если у тебя имеется код, который десятилетиями не меняется, то и смылся ни в тестах ни в интерфейсе, ни в DI для него нет
Это высказывание ложно по стольким параметрам, что даже лень начинать.

T>>и если у тебя имеется код, который десятилетиями не меняется, то и смылся ни в тестах ни в интерфейсе, ни в DI для него нет
·>Это высказывание ложно по стольким параметрам, что даже лень начинать.
ну так и помолчи, раз тебе уже давно нечего сказать

Здравствуйте, IT, Вы писали:

AA>>Например, командная разработка. Интерфейсы согласованы и лежат в общей сборке. Один работает над клиентом, другой над реализацией интерфейса.

IT>А проблема в чём? Зачем тут интерфейсы? К тому же, насколько мне известно, командная разработка это больше об SMS, чем об интерфейсах.

Как минимум в том, что если клиент явно создает экземпляр класса, то ему придется ждать рабочую версию библиотеки.
Если же библиотека будет поломона, то разработка клиента также встанет. Вы не сможете обновить клиента, пока у вас нет новой версии библиотеки.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, varenikAA, Вы писали:

AA>>// Что тут неявного?
·>Непонятно кто от кого и как зависит.

AA>>Зато точка сборки приложения одна а не размазана по разным сборкам.
·>Просто делай то же самое, но без контейнера. Если я правильно разгадал твой код:

·>

·>var dbOptions = new DbOptions()
·>    .UseSqlServer(Configuration.GetConnectionString("DefaultConnection"));
·>var dbContext = new DbContext(dbOptions);
·>var mainService = new MainService(dbContext);
·>services.AddHostedService(mainService);
·>

·>Код внезапно стал проще — никаких лямбд, генериков, рефлексии, даункастов. Можно использовать IDE вовсю — find usages, declarations, использовать рефакторинги.

Серьезно? "найти все ссылки" работает прекрасно и в первом случае.
Рефакторинг? Назовите хоть одну проблему.
DI никуда ни делся, только добавили кучу не нужных new.
От интерфейсов м механизма DI все равно никуда спрятаться в клиентском коде, хотя для получения ссылки, хоть для создания локального скоупа,
либо придется всюду делать ссылку на реализацию. Это отлично работает если у вас развитые средства рефакторинга, но это признак сильных зависимостей.

Вообще если посмотреть на техники ФП, то там все на интерфейсах(любая функция по сути это он и есть),
только за счет возможностей ЯП еще и вызов зависимости выносится за скобки, т.к. есть возможность создавать
вычислительные выражения.

"польза" Dependency Injection для ЯП типа C# очевидна. Не понимаю, почему нужно изобретать велосипед, когда есть отличная билт-ин реализация в коре(быть может вы все еще работает на легаси, тогда — да, только лисопед)?

Здравствуйте, varenikAA, Вы писали:

AA>Серьезно? "найти все ссылки" работает прекрасно и в первом случае.
AA>Рефакторинг? Назовите хоть одну проблему.
AA>DI никуда ни делся, только добавили кучу не нужных new.
AA>От интерфейсов м механизма DI все равно никуда спрятаться в клиентском коде, хотя для получения ссылки, хоть для создания локального скоупа,
AA>либо придется всюду делать ссылку на реализацию. Это отлично работает если у вас развитые средства рефакторинга, но это признак сильных зависимостей.

AA>Вообще если посмотреть на техники ФП, то там все на интерфейсах(любая функция по сути это он и есть),
AA>только за счет возможностей ЯП еще и вызов зависимости выносится за скобки, т.к. есть возможность создавать
AA>вычислительные выражения.

AA>"польза" Dependency Injection для ЯП типа C# очевидна. Не понимаю, почему нужно изобретать велосипед, когда есть отличная билт-ин реализация в коре(быть может вы все еще работает на легаси, тогда — да, только лисопед)?

Вроде, про полезность интерфейсов никто не спорит.
Изначальная мысль была: "Просто делай то же самое, но без контейнера."

Здравствуйте, takTak, Вы писали:

T>система при DI делится на кучу заменямых компонентов, так что сделанные изменения проще тестировать,
T>если все прошлые изменения покрыты тестами (а когда есть DI, это сделать в разы проще), то прогонка этих же регрессионных тестов может указать на явные ошибки, когда ни тестов ни нет, то поддержка по становится чем-то вроде ходьбы по канату на высоте 100 метров без страховки
T>применимо это к так называемым оо — системам, при фунциональщине тесты базируются на иной парадигме, там композиция делается по-другому

Понял. Спасибо. Вопрос: в описываемом случае с легаси ограничитесь извлечением интерфейсов или еще и DI-контейнер используете?

Здравствуйте, TG, Вы писали:

TG>Вроде, про полезность интерфейсов никто не спорит.
TG>Изначальная мысль была: "Просто делай то же самое, но без контейнера."

Если разным частям приложения нужны общие объекты, то без контейнера не обойтись, просто это будет велосипед.
Конечно, если это хеловорд, то можно без DI-контейнера, но вопрос как раз о зависимостях как таковых, а не о контейнере который упрощает работу с зависимостями (см тему).

T>>система при DI делится на кучу заменямых компонентов, так что сделанные изменения проще тестировать,
T>>если все прошлые изменения покрыты тестами (а когда есть DI, это сделать в разы проще), то прогонка этих же регрессионных тестов может указать на явные ошибки, когда ни тестов ни нет, то поддержка по становится чем-то вроде ходьбы по канату на высоте 100 метров без страховки
T>>применимо это к так называемым оо — системам, при фунциональщине тесты базируются на иной парадигме, там композиция делается по-другому

TG>Понял. Спасибо. Вопрос: в описываемом случае с легаси ограничитесь извлечением интерфейсов или еще и DI-контейнер используете?

в этой ветке я уже в другом месте писал, что для новых проектов смысла в DI без IoC контейнера не вижу: слишком много приходится делать тогда своими ручками, сo старым же проектом трудно оценить, насколько безопасно и оправданно его переписать так, чтобы можно было бы покрыть критические части, которые будут изменяться, юнит или ещё какими тестами

вообще, из этого топика я понял, что есть .ева куча народа, которая пользуется DI лишь для композиции приложения из разных кусков, совершенно не задумываясь о таких вещах, как тестирование, имхо тогда смысла в DI просто нет: тогда , действительно, возникает сложно собранная гибкая система, гибкость которой ни в каких тестах не используется, а в других местах гибкость редко имеет смысл, ну тут приводили в качестве примера какие-то плагины: ну там это требование на уровне используемого фреймворка, ну такое...

если же ты начинаешь писать тесты, то тогда польза от использования IoC container сразу налицо: все архитектурные промахи (а для меня они заключаются в том, что невозможно или крайне трудно написать изолированные юнит-тесты ) сразу же явно проступают, но какое-то время на изучение того, что такое IoC container и с чем его едят, уходит, я бы тут порекомендовал почитать какую-нибудь книжку под заданный язык o DI и книжку про тестирование, чтобы было понятно, к чему надо стремиться

Б>·>А ещё многие не понимают разницу между выделением интерфейсов, IoC, DI, контейнерами.
Б>Да, в этом топике идет спор и про DI vs не-DI, и про "Pure DI" vs "DI Container".

я поднимал вопрос лишь о "Pure DI" vs "DI Container" — "DI-фреймворки" в моей формулировке
да и для "Pure DI" вообще не следовало придумывать отдельного названия, настолько это примитивно

T>>Если кода мало и он примитивный это не означает, что он какой-то неправильный, тебе просто непривычно после контейнеров-то.

если это не сарказм конечно, то уточню:

если кода мало (измеряется в количестве стейтментов, выражений, цикломатической стоимости),
то это скорее всего значит что он хороший
кратчайший код — вероятно лучший
бывают исключения, когда несмотря на краткость он трудно понимаемый
но если он ещё и примитивный, то это вообще критерий хорошего кода

Здравствуйте, Министр Промышленности, Вы писали:

МП>я поднимал вопрос лишь о "Pure DI" vs "DI Container" — "DI-фреймворки" в моей формулировке
МП>да и для "Pure DI" вообще не следовало придумывать отдельного названия, настолько это примитивно

Ну, здесь еще спор про "Использование DI в частных случаях" и "DI как принцип построения всего приложений"
Во втором случае для создания объектов не нужны никакие хелперы и статические методы (в самих классах)