Здравствуйте, 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.