2010-06-03 10 views
21

En la última versión de MVVM-luz (V3 SP1) de ambos "Desechar()" y "Dispose (bool)" métodos de la clase ViewModel están marcadosCleanup vs Dispose (bool) en MVVM luz

No use más este método, se eliminará en una versión futura. Uso ICleanup.Cleanup() en lugar

¿Quiere esto decir que la interfaz IDisposable no debe ser implementado en todas las clases ViewModel que se derivan de GalaSoft.MvvmLight.ViewModelBase (y la limpieza deben ser overrided)?

En caso afirmativo, no se puede usar con las instancias de view-model ... Probablemente no entendí algo ... Aclare ... ¿Cuáles son los beneficios de tal limpieza?

Gracias.

Respuesta

27

El problema es histórico. Al principio pensé que sería una buena idea obligar a todas las máquinas virtuales a ser identificables. Sin embargo, IDisposable tiene una intención diferente: una vez que la máquina virtual está dispuesta, se espera (por convención) que se recolectará la basura lo antes posible. Después de hablar con amigos, me doy cuenta de que forzar a todas las máquinas virtuales a ser identificables fue un error. Es por eso que reemplacé IDisposable por ICleanup. El objetivo de ICleanup es proporcionar una forma de limpiar máquinas virtuales (por ejemplo, enjuagando su estado para un almacenamiento persistente, cerrando flujos, etc.) pero no necesariamente de forma que se recolecten basura lo antes posible.

Nada le impide hacer que sus VM implementen IDisposable. Simplemente no quería mantener esta restricción en la clase ViewModelBase, por lo que esta interfaz se eliminará en V4.

La ventaja de tener ICleanup es que puede limpiar todas sus máquinas virtuales en una sola llamada de ViewModelLocator.Cleanup(). Es una sugerencia para los desarrolladores de VM que dicen que las VM deberían pensar en proporcionar un método de limpieza para sus máquinas virtuales.

¿Tiene sentido? Cheers, Laurent

+0

Gracias por comentario, que sin duda hacen SENCE si es necesario tener viable VM después de su clening ... Pero no veo una razón para limpiarlo sin disponer. .. Por lo general estoy rechazando VM en su cierre ... ¿por qué tengo que limpiarlo sin cerrar? Seré apreciado con cualquier comentario. gracias de nuevo. – Budda

+4

@Budda lo que creo que LBugnion está diciendo es que el concepto que estaba usando para IDisposable ya estaba sobrecargado con la idea de GC el objeto lo antes posible. Sin embargo, muchos de nosotros usamos el mismo objeto VM una y otra vez, así que en lugar de deshacernos del objeto, ViewModelBase recibió una interfaz ICleanUp cuyo propósito es limpiar el VM Clean para que pueda volver a usarse. Esto puede ser útil si está haciendo una primera aproximación de máquina virtual, WPF no eliminará la vista y luego la volverá a crear, sino que se limpiará como la máquina virtual. – Agies

+0

Gracias. Está claro ahora – Budda

2

Creo que debo discrepar un poco con Laurent en este punto. La idea detrás de IDisposable es que el objeto puede tener cierta limpieza que debe llevarse a cabo y no tiene nada que ver con la recolección de basura. De hecho, la mayoría de las veces IDisposable se implementa para limpiar recursos no administrados, como manejadores de archivos, objetos de sincronización o conexiones de bases de datos, que están fuera del ámbito del GC. Además, el hecho de que una clase base implemente IDisposable no significa que deba tener una implementación real. Eso se puede relegar al método Dispose (bool disposing) virtual que puede ser anulado por las clases derivadas para que puedan realizar la limpieza.

El problema, como lo alude Budda, es que IDisposable es, por convención, una operación unidireccional. Una vez que un objeto ha sido eliminado, debe arrojar una ObjectDisposedException en sus métodos públicos. Si todo lo que quiere hacer es eliminar recursos para que pueda reutilizar el objeto, entonces tiene sentido un método de limpieza. Sin embargo, no eliminaría necesariamente la funcionalidad Dispose, que tiene un propósito diferente.

+1

Se requiere liberar recursos no administrados en el método Finalize. También podría forzar al sistema a liberarlos durante la eliminación y suprimirlos en este caso (vea el patrón de implementación del método "Eliminar") – Budda

2

Pequeña historia "interesante": al haber encontrado programadores en mi equipo no había cancelado la suscripción a eventos, me 'lavaron' la jerarquía de modelos de vista solo para cambiar de opinión sobre si Dispose era el lugar correcto.

En algunas circunstancias, fue difícil llamar a Dispose debido a MEF y algunas otras formas funky en las que creamos nuestros modelos de vista. Esto me hizo preguntarme si era correcto.Y luego está el hecho de que botar necesita algún tipo de atención (y un fragmento) para hacerlo bien:

DG Update: Dispose, Finalization, and Resource Management

Más tarde, hice un trabajo de fin de semana en una aplicación WP7 (donde uso MVVM Light) y notamos el cambio de Laurent de corazón, también.

Creo que es la decisión correcta; IDisposable envía un mensaje que el "cliente" debe intentar y ajustar el uso de la clase en un uso() o de otra manera lavarse las manos de la instancia CUANTO ANTES.

Originalmente, estuve de acuerdo con la respuesta aceptada en el hilo a continuación, pero luego comencé a pensar que JaredPar tenía razón.

Using IDisposable to unsubscribe events

Lucas