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

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

hVosttвот я не пойму что ты имеешь в виду под "изучи ООП"? взять одну из классических книжек по ООП, там на 100 листов полезных листа 2, остальное — неумный пеар, как ООП спасёт мир.
Ну ты ведь вопишь о том, что наследование УГ и старпёрство. А я тебе говорю, что ты просто еще не силён в этом. Вот я и говорю, что изучи.

hVosttдаж GoF-паттерны и те в осномном применимы лишь для построение библиотек и фреймворков. для построение архитектуры конечных приложений применяеются композиция, а не наследования. хрен ли там от ООП толку .
Бестолочь ты. Прости меня Бог...

Вот тебе пример: обычная с виду базовая вью модель "ака привет мир" (да, я знаю, как ты не любишь наследование с виртуальными методами):
Но тем не менее, смотри, сколько она может: и подчищать хвосты, и нотифицировать, и валидировать. Бери, наследуй и пиши с минимумом кода.



Что тут плохого?

hVosttМСУВ том же WPF отдельная абстракция IWindowService (выполняет роль презентёра):
ну а нафига? зачем словно сопли по кафелю размазывать ответственность по классам? кто выдал инстанс, тот пусть будет добр его и уничтожит. сам создал? сам и убей.
Батенька, про разделение ответственности ничего не слыхал? Какие сопли? Часто бывает так, что нужно подчищать хвосты при определенной логике, это будет посложнее простого окончания реквеста. Например, подчистить ссылку при закрытии окна в XAML. Заметь, это не WinForms, окно не реализует никаких IDisposable. Твои действия? :)

МСУВот тебе пример: обычная с виду базовая вью модель "ака привет мир"...
Только что заметил, что эта модель с Expression<Func<T>> propertyExpression Твоя тема!

Где-то в степичто то вот сижу и не догоняю.
предположим контейнер выдал нам объект, если - наблюдатели не участвуют, подсчет ссылок не ведется, контейнер не привязан ни к одному внешнему событию, сквозной интеграции в код нет то как он знает что объект уже бесхозный и что его можно диспозить?
Спасибо...
Тогда время жизни объекта будет такое же, как и время жизни контейнера. Что-то типа реализации ContainerControlledLifetimeManager от Unity.

Где-то в степиМСУ, ну это не интересно, в принципе ничего тут ништяковского нет, создание контейнера должно быть на раз и легкое, хочся
ПРОСТО писать код, а о зачистке пускай заботится контейнер ( так сказать дублирование функции коллектора)
Я выше озвучил задачу на XAML. Как контейнер должен угадать, что закрывается такое-то Window и что нужно подчистить такие-то объекты?

Где-то в степиМСУ, Я это видел - спасибо, но оппонент вроде отвергает это ( скорее не отвергает, а говорит что есть лучше фишка) , и имеет свою точку зрения, вот с его точки зрения я и рассуждаю, твой код раннее просмотрел ( целых два раза)
Оппонент и вчера отвергал информацию о том, что лямбда компилируется в делегат. Пока по зубам ему не настучали... :)

Где-то в степи, в общем варианте MVVM решение такое (хвосту не читать, который меряет жизнь одним шаблоном):

Вот вью модель. После инжектирования в неё DI контейнера, она резолвит нужный объект, использует его и уничтожает. Всё.
В следующий раз контейнер опять отдаст новый экземпляр. Диспоузить по требованию очень важно - например ситуации с веб сервисами, жизнь инстанса сервиса должна быть как можно короче. Попользовал пару методов и грохнул опосля. Ни один контйнер не сможет угадать тот момент времени, когда нужен Dispose. Я и только я знаю этот момент.

Код:

Где-то в степида бог с этим, контейнеры - банальный код ( как квадрат малевича ) но в то же время можно говорить о них годами, ибо разные исполнения обросли разными вкусняшками, можно как Чапай ( В.И.) - написать свой..
О чем и речь. Но он замахивается на наследование, на ООП. Говорит, что это УГ и старпёрство. Каким нужно быть близоруким прыщавым студнем, что бы писать такие вещи? :)

Где-то в степипожалуй соглашусь, что "временем жизни" должен управлять кто заказал инстанс, а не кто его смастерил,
+1К, только попробуй это объяснить студенту, который мыслит одним шаблоном, вброшенным в букварь, который он сейчас читает... Это всё от неопытности. Ничего, я сделаю из него человека Но уж много энергии уходит на этого мальчёнку, однако. Давишь его, как прыщ, а он уворачивается и вскакивает в другом месте. Давишь там - он опять прыгает как заяц. Пока не выдавишь, не успокоится.

Так и по сабжу, доипался студень до мвц-шного DependencyResolver, мол инжектить не умеет Объяснил на пальцах, как можно пукалку сделать. Начал горланить, мол этот функционал должен быть вшит в DI конейнер. Оскорбил замечательный DependencyResolver сервис локатором. Объяснил на пальцах, что помимо локаторности, DependencyResolver обладает еще двумя фишками - может описывать зависимости и регистрировать их. Далее, начал он орать, что мол нету управлением жизни. Объясняю на пальцах, что DependencyResolver - это простенький контейнер, без наворотов. Что-то типа легковесного SimpleIoC . Не доходит... Потом начал гнать на ООП, это вообще песня. Потом понесло его ветром в сторону того, кто и как должен диспоузить. Вообщем, цирк

Где-то в степиМСУ, ох и любишь ты потоптаться на костях
Топтаться не цепляет, а вот станцевать твист на костях подопытных кодеманок - вот оно че, Михалыч

Ух ты кто пожаловал сюда, не уж-то фееричная сильверлайтная обезьяна без ума и фантазии?
Шагом марш читать букварь, чем тебя так напугал диспоуз сервиса в ctor вью модели? Хотя чего это я, дальше хеллоуворлдных пукалок на тухлом призме у тебя нет и не было. Впрочем это и так видно невооруженным глазом, когда читаешь твой высер про вью модель и контейнер. Откуда знаешь про контейнеры, нагуглил? Вообщем, джуниор девелопер, рано тебе еще тут гадить, иди лучше детвора расскажи про генерацию сборок в памяти. Пусть посмеются над идиотом.