Cleanup против Dispose (BOOL) в MVVM света

Question

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

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

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

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

Спасибо.

Answer 1

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

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

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

Это имеет смысл? Cheers, Laurent

Answer 2

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

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

Answer 3

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

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

DG Update: Dispose, Finalization, and Resource Management

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

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

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

Using IDisposable to unsubscribe events

Люк