Замок Windsor IoC - утечка памяти с помощью ссылок Singleton/Transient

Question

У меня есть приложение WPF, в котором используется IOC и шаблон корневой композиции с введением конструктора. Большинство параметров в конструкторах View Models являются репозиториями. Некоторые из репозиториев используют Singleton Lifestyle, поскольку они кэшируют материал. Все модели просмотра являются переходными, так как я хочу, чтобы память была выпущена сразу после закрытия представления.

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

Есть ли шаблон, который я могу выполнить, чтобы освободить классы, когда они больше не используются? Я думал о реализации IDisposable в ViewModels и просто устанавливал ссылки на репозитории на null, но это звучит не так.

Answer 1

Согласно блог одного из коммиттеров из Castle Project:

Must I release everything when using Windsor?

Переходные компоненты аналогичны объединен, потому что это не хорошо известный конец жизни транзиторной компоненты и Виндзор не будет знать, если вы все еще хотите использовать какой-либо компонент или нет, если вы явно не указали это (вызвав Release). Поскольку переходные компоненты по определению не разделяются, Windsor немедленно уничтожит компонент при его выпуске.

Согласно еще одному из своих постов:

Must Windsor track my components?

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

---

Теперь серьезно - часто люди видят, что Виндзор держит на компонентах, которые она создает, как утечка памяти (это часто бывает, когда используется ненадлежащим образом, который я буду говорить в следующем посте), и они идут - Windsor, удерживающий объекты, вызывает утечку памяти, поэтому позволяет использовать NoTrackingReleasePolicy, и проблема решена.

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

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