Очистка от удаления (bool) в MVVM-light

Question

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

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

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

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

Спасибо.

Answer 1

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

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

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

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

Answer 2

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

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

Обновление ГД: удаление, финализация и управление ресурсами

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

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

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

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

Люк

Answer 3

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

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