Замок Windsor - Я должен выпустить одиночный элемент или недоступные временные объекты?
Wiki Замка говорит в нескольких местах, что я должен ВСЕГДА называть контейнер. Выпуск () для компонентов, разрешенных через контейнер. Это, очевидно, имеет смысл для сложных методов управления образа жизни (например, LifeStyle. Объединенный) или при использовании специализированных средств...
Но я должен действительно выпустить одиночный элемент (которые живут, пока контейнер не расположен), и недоступные временные объекты? Если я ступаю посредством Выпуска (), призывает к временным объектам или одиночным элементам, эти вызовы, кажется, являются лишними - .e.g. в случае временных объектов, не реализовывая IDisposable ядро просто замечает, что не имеет никакой дорожки объекта и возвратов...
Кажется, существует понятие "нагрузки компонента" для отслеживания "косвенных" ссылок на другие доступные компоненты, которые могли бы быть созданы при разрешении временного объекта. Я понимаю, что необходимо выпустить временные объекты, если Вы не знаете 100%, есть ли у них такие косвенные зависимости или нет. Действительно ли это - главная причина "убедить" всех пользователей Замка ВСЕГДА выпустить компоненты?
1 ответ
Castle Wiki здесь немного строга - скорее пытаюсь перестраховаться, чем сожалеть. Возможно, там нужно было бы немного переформулировать.
В общем, вот как это работает.
Windsor (по умолчанию) отслеживает большинство компонентов и содержит ссылки на них, что мешает сборщику мусора их собрать. Это не ошибка - это очень полезная и мощная функция. В большинстве случаев не следует предполагать, будет ли отслеживаться компонент или нет. Также будет отслеживаться одноразовый компонент, имеющий одноразовые зависимости. Это общее правило: « компоненты, которые сами или некоторые из их зависимостей имеют какие-либо шаги вывода из эксплуатации, отслеживаются политикой выпуска по умолчанию в Виндзоре ».
Итак, вот часть, где в игру вступают жизни.
Синглтоны - по определению синглтоны являются «глобальными» в контексте контейнера - они создаются, когда вы их впервые запрашиваете, и живут до конца срока службы контейнера (то есть до тех пор, пока контейнер не будет удален).Если вы видите документацию, на самом деле в ней говорится, что выпуск синглтонов на самом деле ничего не делает. Проблемы вывода из эксплуатации компонентов вашего жизненного цикла будут вызваны только после того, как контейнер будет удален.
Per (context: веб-запрос / WCF Session /) - поскольку объект используется совместно в четко определенном контексте с четко определенным концом, конец контекста позаботится об освобождении ваших компонентов.
Переходный процесс - вот где могут закрасться настоящие проблемы. Поскольку временные компоненты не имеют произвольного конца срока службы и вы можете создавать кучи их экземпляров в течение всего срока службы приложения, нет другого пути, кроме как явное и говоря контейнеру: «Эй, я больше не собираюсь использовать этот объект, не стесняйтесь избавляться от него, спасибо за всю рыбу».
Причина, по которой в документации предлагается всегда выпускать компоненты, заключается в том, что код который использует компоненты, на самом деле не должен знать, каков срок службы компонента. Это не всегда так, и часто в приложениях есть компоненты, которые «естественно» соответствуют образу жизни. Однако в целом, как я уже сказал, нужно скорее перестраховаться, чем сожалеть.
Другое дело, где вы вызываете Resolve и Release . Вы должны Выпустить только то, что вы Разрешите .
Когда вы используете контейнер аналогично тому, как это делаю я , возможно, вам не придется вызывать Release где-либо в вашем коде. Вы разрешите свой корень, но Dispose самого контейнера позаботится о его освобождении.Скорее всего, вы также разрешите другие компоненты неявно через типизированные фабрики, и в этом случае вы также должны выпустить их (через фабрику), но обычно это так.
Итак, конечный результат не так страшен, как кажется на первый взгляд.