Очистка vs Dispose (bool) в MVVM-свете

В последней версии MVVM-light (V3 SP1) методы "Dispose()" и "Dispose (bool)" в классе ViewModel помечены

Не используйте этот метод больше, он будет удален в будущей версии. Вместо этого используйте ICleanup.Cleanup() вместо

Означает ли это, что интерфейс IDisposable не должен реализовываться во всех классах ViewModel, которые получены из GalaSoft.MvvmLight.ViewModelBase(и очистка должна быть переопределена)?

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

Спасибо.

Ответ 1

Проблема историческая. Сначала я подумал, что было бы неплохо заставить всех виртуальных машин быть IDisposable. Однако IDisposable имеет другое намерение: после того, как VM будет Disposed, ожидается (по соглашению), что это будет сбор мусора как можно скорее. Поговорив с друзьями, я понимаю, что заставить всех виртуальных машин быть IDisposable ошибкой. Вот почему я заменил IDisposable на ICleanup. Цель ICleanup - обеспечить способ очистки виртуальных машин (например, сброс их состояния в постоянное хранилище, закрытие потоков и т.д.), Но не обязательно таким образом, что они будут собираться как можно скорее.

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

Преимущество ICleanup в том, что вы можете очистить все свои виртуальные машины одним вызовом ViewModelLocator.Cleanup(). Это подсказка для разработчиков VM, говорящих, что виртуальные машины должны думать о предоставлении метода очистки для своих виртуальных машин.

Это имеет смысл? Ура, Laurent

Ответ 2

Думаю, я прошу немного поразмышлять с Лораном по этому вопросу. Идея IDisposable состоит в том, что объект может иметь некоторую очистку, которая должна иметь место и сама по себе не имеет никакого отношения к сбору мусора. Фактически, большая часть времени IDisposable реализована для очистки неуправляемых ресурсов, таких как дескрипторы файлов, объекты синхронизации или соединения с базой данных, которые не входят в компетенцию GC. Кроме того, только потому, что базовый класс реализует IDisposable, не означает, что он должен иметь реальную реализацию. Это можно отнести к виртуальному методу Dispose (bool disposing), который может быть переопределен производными классами, чтобы они могли выполнять очистку.

Проблема, по мнению Будды, заключается в том, что IDisposable по соглашению является односторонней. Когда объект был удален, он должен вызывать ObjectDisposedException в своих общедоступных методах. Если все, что вы хотите сделать, это очистить ресурсы, чтобы вы могли повторно использовать объект, то метод очистки имеет смысл. Тем не менее, я бы не обязательно удалял функциональность Dispose, которая выполняет другую цель.

Ответ 3

"Интересная" небольшая история: найдя, что программисты в моей команде не отменяли подписку на события, я "промыл" IDisposable по нашей иерархии модели представлений, чтобы изменить свое мнение о том, было ли Dispose правильным местом.

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

Обновление DG: удаление, завершение и управление ресурсами

Позже я сделал некоторые выходные работы в WP7-приложении (где я использую MVVM Light) и заметил изменение сердца Лорана.

Я думаю, что это правильное решение; IDisposable отправляет сообщение о том, что "клиент" должен попытаться обернуть использование класса в use() или иным образом вымыть руки экземпляра ASAP.

Изначально я согласился с принятым ответом в нижеприведенном потоке, но потом начал думать, что JaredPar прав.

Использование IDisposable для отмены подписки

Лука