usar tutorial porque patron implementar example español ejemplo como .net wpf design-patterns mvvm inotifypropertychanged

.net - tutorial - xamarin forms mvvm ejemplo



En el modelo MVVM, ¿debería el modelo implementar la interfaz INotifyPropertyChanged? (6)

Tengo una idea clara sobre View y ViewModel en el patrón MVVM. Estoy planeando implementar el patrón MVVM en mi aplicación. Estoy enfrentando un problema con respecto al modelo. Tengo un archivo .xml que se analiza y la información se muestra en la Vista.

Necesito ser notificado sobre los cambios en el modelo por primera vez solamente. De aquí en adelante a petición necesito ser notificado.

Entonces, ¿cómo implementar el modelo?

¿Debo implementar INotifyPropertyChanged interfaz INotifyPropertyChanged en la clase de modelo? (He leído que el modelo no debe implementar la interfaz INotifyPropertyChanged , ya que es específico de WPF)


Algunas veces es aceptable que el modelo implemente la interfaz INotifyPropertyChanged .

Por ejemplo, si el modelo tiene muchas propiedades para visualizar y desea evitar implementar una gran cantidad de código (propiedades de proxy) en el modelo de vista para exponer dichas propiedades de modelo.

Mira http://msdn.microsoft.com/en-us/magazine/ff798279.aspx


El enfoque MVVM estándar es implementar INotifyPropertyChanged solo en ViewModel. El objetivo es actualizar los enlaces apropiados en la Vista cuando algo cambia en ViewModel.

Sin embargo, esto se dirige a los cambios al ViewModel por la Vista . Es decir, cuando cambia el valor en un TextBox , la implementación INotifyPropertyChanged en ViewModel actualizará los enlaces relacionados, por lo que la vista se actualiza correctamente.

No cubre los cambios realizados en el Modelo por una fuente externa, como cambios en la Base de datos u otra interfaz. Siempre que todas las modificaciones de datos provengan de la Vista, ViewModel debe conocer todos los cambios y saber qué actualizar. Por ejemplo, si sabe que cambiar la variable Foo en su modelo también cambiará el valor de la Bar en su modelo, sería aconsejable llamar tanto OnPropertyChanged(Foo) como OnPropertyChanged(Bar) en su ViewModel cuando cambie el valor de Foo .

La otra alternativa es usar eventos entre el Modelo y ViewModel para actualizar esos valores en ViewModel que requieren actualización. Si, como dices, la notificación se requiere "solo por primera vez", entonces la implementación de un manual una vez que se actualice el disparador también debería funcionar.


Este es un argumento clásico entre los codificadores MVVM "puros" y otros.

Tiendo a los libros siempre que puedo porque la mayoría de las veces tiene sentido. Sin embargo, en ciertos escenarios, la improvisación del código de acuerdo con las necesidades reduce una gran cantidad de código duplicado.

En su caso, puede leer el XML en una clase de modelo y hacer una copia de la clase de modelo al modelo de vista, o copiar las propiedades que desea del modelo al modelo de vista. De esta manera, tiene el control para actualizar la UI / modelo. Si sigue el primer enfoque, debe tener Inotifypropertychanged implemetned en su clase de modelo y es aceptable.

Una vez dicho esto, intentaría mi mejor nivel para seguir el segundo enfoque porque eso me daría un control preciso sobre todas las propiedades que se muestran / manipulan en la vista. Además, me sentiré mucho mejor de que no estoy rompiendo el patrón MVVM.


Este es un problema muy común al trabajar con MVVM, INotifyPropertyChanged no es específico de WPF ya que es parte de System.ComponentModel por lo que no es necesario agregar ninguna referencia específica de WPF en su solución.

Si implementa INofityPropertyChanged en su modelo, puede ahorrar mucho más código en ViewModel (Proxy Properties). Por lo tanto, es aceptable que Model tenga INotifyPropertyChanged .


Implementar INotifyPropertyChanged in Models es totalmente aceptable -

Normalmente, el modelo implementa las instalaciones que facilitan el enlace a la vista. Esto generalmente significa que es compatible con la propiedad y la notificación de cambio de colección a través de las interfaces INotifyPropertyChanged e INotifyCollectionChanged . Las clases de modelos que representan colecciones de objetos normalmente se derivan de la clase ObservableCollection<T> , que proporciona una implementación de la interfaz INotifyCollectionChanged .

Aunque depende de usted decidir si desea ese tipo de implementación o no, pero recuerde:

¿Qué sucede si las clases de su modelo no implementan las interfaces requeridas?

A veces necesitará trabajar con objetos modelo que no implementen las INotifyPropertyChanged , INotifyCollectionChanged , IDataErrorInfo o INotifyDataErrorInfo . En esos casos, el modelo de vista puede necesitar envolver los objetos modelo y exponer las propiedades requeridas a la vista. Los valores de estas propiedades serán proporcionados directamente por los objetos modelo. El modelo de vista implementará las interfaces necesarias para las propiedades que expone, de modo que la vista pueda vincular datos fácilmente.

Tomado de - http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

He trabajado en algunos proyectos donde no hemos implementado INotifyPropertyChanged en nuestros modelos y debido a esto enfrentamos muchos problemas; la duplicación innecesaria de propiedades era necesaria en VM y al mismo tiempo tuvimos que actualizar el objeto subyacente (con valores actualizados) antes de pasarlos a BL / DL.

Te enfrentarás a problemas especialmente si necesitas trabajar con la colección de tus objetos modelo (por ejemplo, en una grilla o lista editable) o modelos complejos; los objetos modelo no se actualizarán automáticamente y tendrás que administrar todo eso en tu máquina virtual.


No estoy seguro de lo que quieres decir. En la VM, puede tener INotifyPropertyChanged o DependencyProperty-es (en este caso, la VM debe derivarse de DependencyObject ). No tiene sentido tener ambos. Tampoco tiene sentido no tener ninguno de ellos.

En el modelo, puedes hacer lo que quieras. La capacidad de disparar / recibir eventos es buena, pero no siempre puedes confiar en ellos. Básicamente, el modelo depende de los datos fuente y de los elementos relacionados, mientras que el modelo de vista tiene la carga de interfaz del modelo con la capa de presentación. Como WPF trabaja sobre eventos, al menos la VM debe proporcionar algún mecanismo de notificación.