Soy bastante nuevo en MVVM, así que discúlpeme si este problema tiene una solución conocida.Propiedades no bloqueadas de carga lenta en el modelo de MVVM
Estamos construyendo un conjunto de clases de modelos que tienen algunas propiedades centrales que se cargan por adelantado, así como algunas propiedades adicionales que podrían cargarse de forma diferida a pedido haciendo una llamada a la API web (actualización: para aclarar, sería una llamada a la API web por cada propiedad cargada de forma lenta).
En lugar de tener varios modelos, parece sensato tener un solo modelo con la lógica de carga diferida allí. Sin embargo, también parece que las propiedades de carga diferida no deben bloquearse cuando se accede, de modo que cuando la Vista se vincula al ViewModel y se une al Modelo, no bloqueamos el subproceso de UI.
Como tal, yo estaba pensando en un patrón algo en la línea de cuando se accede a una propiedad de descanso en el modelo comienza una búsqueda asíncrona y luego regresa inmediatamente a un valor predeterminado (por ejemplo null
). Cuando se completa la recuperación asíncrona, se generará un evento PropertyChanged
para que ViewModel/View pueda vincularse al valor recuperado.
que he probado esto y parece que funciona bastante bien, pero se preguntaba:
- ¿Hay trampas a este enfoque que no he descubierto acerca aún, pero se encontrará con tan la aplicación aumenta en complejidad?
- ¿Existe una solución existente a este problema, ya sea integrada en el marco, o que se usa ampliamente como parte de un marco de terceros?
El posible problema que se me puede ocurrir, es que necesita escuchar el evento PropertyChanged en todos estos cargadores perezosos, lo que significa que si tiene una propiedad o función que depende de varios de estos cargadores, tendrá que espere a que terminen todos los cargadores en los que confía antes de ejecutar su propio código. Esto podría dar como resultado tener que escribir una gran cantidad de lógica que, de otro modo, podría haber sido escrita como una sola llamada con subprocesos que combina la búsqueda de los cargadores perezosos "sincrónicamente" dentro de ese subproceso separado. –
@Timothy - Buen punto. Ya he pensado sobre eso, y tengo la sensación de que, debido a la naturaleza de los datos cargados de forma perezosa, es poco probable que algo dependa de múltiples datos perezosos. Es probable que varias cosas dependan de una sola pieza de datos perezosos, pero no creo que eso represente un problema. –
Uso el enfoque exacto que describes arriba y funcionó muy bien. – Jeff