МСУЭто стандартная практика.

только у тебя это стандартная практика . если не так изволь доказать свои слова. не будь обычным словплётом.

ты уже сам оговорился:

МСУЯ лучше передам один контейнер, чем 100500 сервисов.


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

вот банальный пример. если для того, чтобы сменить Unity на Autofac (или наоборот, на важно), нужно перелопать половину кода, это говорит о том, что код -- унылое говно. почему? разве это не очевидно? никакой слабой связности и впомине нет. есть какой-то высер. просто ради того чтобы было. нафига казе баян, ещё раз? выкинь тогда ты эти контейнеры на помойку и пиши всё сам как считаешь нужным.

МСУв любом случае обеспечивается слабосвязность, никаких нарушений тут нет

и нарушение есть. очень сильное при чём. передавая контейнер, ты поручаешь компоненту самому резолвить свои зависимости. нахуа? тогда? контенейр? этот? нужен?

задача DI -- обеспечивать слабую связность. а не дать Service Locator для самостоятельного разруливания своих зависимостей.

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

МСУТы долго будешь тут исповедовать религию своего единственного паттерна?

ты дурак? мы говорим о DI. а не о том, лучше он или хуже других подходов. куда тебя несёт?

МСУНарушений нет, есть удобство. Когда когда очень много, мне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов. А потом не забыть поправить инжектинг. Я тупо передаю туда интерфейс контейнера и делов. Класс дальше отрезолвит то, что ему нужно. Это универсальность, стабильность и внятность.

Не понял?

я понял. ты не умеешь пользоваться DI, не понимаешь толком зачем он нужен. путаешь SL и DI. но самое главное не это. самое главное вот это:

МСУмне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов

занавес.

МСУТы кретин? Мы говорим о DI, о чем же еще? Ты тут звездишь о том, что его нельзя подавать классу. Я тебе объясняю, что это бред сивой кобылы. Его спокойно можно отдавать классу. Ты запутался в своих же сетях, рыболов.


вот именно. я тебе говорю что его нельзя подавать конечным классам. существует прослойка для внедрения контейнера DI. в ASP.NET MVC она предельно чёткая. это фабрики (контроллеров, вью..)

это позволяет забыть об использовании DependencyResolver. вообще.

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

МСУЯ понял, ты не умеешь писать код, никогда не писал боевой код, только читаешь книжки и поносишь в форум какую-то несусветщину. Аплодисменты.

давай, трепыхайся. ещё что скажешь?

МСУ,

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

МСУМожно много чего, нужно просто иметь прямые руки.

мы не о прямых руках. мы обсуждаем исключительно паттерн DI. я понимаю, что это не панацея, и что прямые руки нужны и голова и всё такое. что не всегда уместно пихать DI, и не надо пытаться сделать +100500 слоёв обстракции... и т.д. и т.п.

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

да в контексте DI диспозить должен контейнер и я уже объяснил почему. могу повторить:

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

будут какие-то опровергающие аргументы с твоей стороны?