МСУПонесло обезьянку

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

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

МСУ, можешь даже стараться.
я не собираюсь больше продолжать тему, если тебя уже на обезянки понесло.

МСУКлассический вариант - открываем окно, идет обращение к WCF сервису, после получения данных инстанс сервиса диспоузится. Где решение?

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

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

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

всё что я говорил, относится к паттерну DI. к чистому паттерну DI. это когда никакие DependencyResolver или App.Container не используются. никто не резолвит ничего самостоятельно. если тебе кажется, что такие подходы не практикуются, уверяю тебя — это не так. ещё как практикуются.

МСУТы говоришь о некой серебряной пуле.

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

ViPRosиногда как можешь круче чем учиться у козлов каких то



и такая точка зрения тоже имеет право на жисть. в сраку ваших Фаулеров, прямые руки и пошёл!...

ViPRosвсе эти высеры типа ДИ и т.д. латают дыры в ООП, но фигушки, эти дыры бездонны

абстракции текут

МСУПроблема в том, что эту именованную абстракцию области жизни как-то должен протащить в класс. Опять нагружать конструктор. Далее. Класс должен будет в нужный момент сказать, когда выгрузить именованную область. Что по сути те же яйца, что и обычный диспоуз сервиса. Прицнип тот же самый.

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

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

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

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

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

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

МСУ,

кстати, Autofac, например, определяет свою фабрику зависимостей, которую можно прокидывать в класс, если он в момент создания ещё не уверен какая конкретно реализация зависимости ему понадобится:




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

проблемный класс:




решение:




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