2010-01-06 20 views
5

He estado buscando en MVVM recientemente y parece que tengo la idea general. Sin embargo, hay un par de cosas que no entiendo del todo y estaba buscando respuestas, ¡salud!Algunas preguntas MVVM (WPF C#)

  1. ¿Es incorrecto utilizar un modelo de datos para toda la aplicación. Por lo general, si estoy creando una pequeña utilidad, tendría todos los datos lógicos en una clase. Esto significa que puedo tener tantos como las siguientes:

    DataStore myData = new DataStore; 
    
  2. Si está bien tener un modelo de datos ¿Está bien tener más de una vista de modelo, por ejemplo uno en representación de cada ventana o ver (Así es como yo visualizar MVVM funcionando).

  3. Dado que entonces si uno tiene múltiples vistas de modelo, parecería que el modelo debería declararse antes de la primera ventana (vista), ¿dónde debería declararse? ¿debería pasar el modelo a través de una referencia a las vistas de modelos posteriores? ¿No sería esto una fuente de acoplamiento, ya que la ventana o página (vista) necesitaría conocer el modelo para pasarlo a su vista modelo, ya que la vista crea una instancia de la vista modelo.

Lo siento si esto es un montón de preguntas, tengo la idea de MVVM en una sola ventana o página de sentido, pero una vez que puedo agregar varios puntos de vista de mi sistema se rompe. Puedo hacer que funcione con modelos independientes accediendo a una fuente externa para obtener sus datos, pero si los datos deben persistir entre las vistas, me pierdo.

¡Gracias a todos los que se toman el tiempo para responder!

+0

Me gustaría agregar.¿Debería un modelo enviar los datos a una fuente externa si los datos deben persistir entre los diferentes modelos? ¿El modelo solo está moviendo datos entre el almacenamiento y la vista del modelo? – deanvmc

Respuesta

5

Algunos pensamientos:

  1. aplicaciones simples no requieren necesariamente la complejidad de MVVM - usted puede ser capaz de salirse con la eliminación del modelo de vista - y usar directamente el modelo subyacente. Solo tenga cuidado de no estirar este enfoque hasta el punto de ruptura, ya que WPF depende mucho de cosas como INotifyPropertyChanged y DependencyProperties. No desea comenzar a fusionar estos en sus clases modelo innecesariamente.

  2. Sí, está bien. Sin embargo, ... tenga en cuenta que es más simple si solo hay una instancia del Modelo; de lo contrario, deberá tratar la fusión de cambios desde varias vistas cuando va a guardar (o perder los cambios de una versión). Si ViewModels se refiere al mismo modelo subyacente, esto puede ser viable.

  3. No se puede evitar un cierto nivel de acoplamiento en MVVM. Sin embargo, (si entiendo correctamente su pregunta), la introducción del acoplamiento entre ModelViews probablemente sea una mala idea, ya que está frustrando el propósito de hacer de cada una una perspectiva discreta del modelo optimizada para una vista particular.

+1

Absolutamente de acuerdo: uno de los beneficios de la arquitectura de enlace de datos es que puede trabajar en una arquitectura simplificada de vista de modelo y escalar hasta el enfoque MVVM más complejo solo cuando sus vistas comiencen a exigirlo. Y no rehuiré la implementación de INotifyPropertyChanged en sus clases modelo para soportar esa arquitectura más simple (aunque estoy de acuerdo una vez que empiece a necesitar desplazar los DP probablemente esté en el territorio del modelo de vista). – itowlson

+0

Sí entendió correctamente. Entiendo que podría salir adelante acortando el proceso pero estoy intentando (frustrantemente puedo agregar) aprender MVVM antes de asumir aplicaciones más grandes. Parece que mi problema general es la persistencia de datos entre modelos. Tal vez tengo el concepto de un modelo equivocado, editaré mi publicación para reflejar esto. – deanvmc

+1

Debe evitar tener MV's responsables de administrar datos persistentes. Deberían inmediatamente (o en puntos claramente definidos) fusionar sus cambios en las clases modelo subyacentes. Esto evita tener que lidiar con la diferencia de persistencia entre diferentes vistas. – LBushkin

1

mi propia experiencia:

  1. No veo nada malo con el uso de un modelo de datos para toda la aplicación, dependiendo de lo que están queriendo hacer. Siempre que lo mantenga separado de su Vista, se queda dentro del patrón de diseño MVVM.

  2. Personalmente me gusta usar ModelView para cada una de mis vistas. Creo que hay diferentes argumentos al respecto, pero personalmente creo que todo se mantiene más modular y que la unidad se puede probar haciendo esto.

  3. Intento evitar el acoplamiento entre ModelViews. Si tengo un ModelView para cada una de mis vistas, declaro cada ModelView por separado en cada una de las vistas. Luego instanciar cada vista en mi vista principal a través de eventos. Esto se mantiene con el patrón MVVM, y usted puede probar cada una de sus ModelView por separado.

No me sorprendería si ya ha leído este artículo, pero para aquellos que por ahí que quieran aprender sobre el diseño MVVM He aquí una buena Link.

+0

¡Santa vaca que es un artículo denso, no pretenderé entender todo, pero al menos me da una lista de cosas por hacer! ¡Gracias! – deanvmc

1

No es correcto utilizar un modelo de datos para toda la aplicación. Normalmente, si estoy creando una pequeña utilidad tendría todos los datos lógicos en una clase. Este significa que puedo tener tantos como el siguiente:

`DataStore myData = new DataStore; ` 

Esto está bien. Su modelo de datos es el modelo de datos y debe representar los datos de la mejor manera posible, ya sea en una clase o 1000.

Si es bien tener un modelo de datos ¿Está bien tener más de una modelo vista, digamos uno que represente cada ventana o vista (así es como yo visualizo el funcionamiento de MVVM).

Absolutamente, en mi opinión, eso es exactamente lo que debe hacer. En general, diría que quiere un modelo de vista por vista, ya sea que una vista sea un control o una ventana. Puede haber casos en los que considere que tener más de un modelo de vista para una vista en particular sería útil, pero primero buscaría asegurarme de no tener una vista dividida.

Dada entonces por encima de si uno tiene múltiples modelo vistas que parecería que el modelo tendría que ser declarado antes la primera ventana (ver), donde debe se declare? ¿Debería pasar el modelo a mediante una referencia a las vistas posteriores del modelo ? ¿No sería esto una fuente de acoplamiento de ya que la ventana o la página (vista) necesitarían conocer el modelo para pasarlo a su vista de modelo ya que la vista crea la vista del modelo .

Ahora está entrando en territorio religioso. Voy a puntualizar un poco sobre esto y decir lo que tiene sentido para su aplicación. Dicho esto, si desea reducir el acoplamiento entre su modelo y sus vistas/modelos de vista, le recomiendo que extraiga una interfaz de su (s) clase (s) de modelo. Sería bastante simple crear su modelo en su archivo App.xaml.cs y luego pasarlo a la vista (modelo) como una implementación de una interfaz.

+0

@ su último punto: pensé que ya que parece ser la parte menos respondida de MVVM La mayoría de los ejemplos muestran ejemplos de uso único, pero todavía tengo que ver un ejemplo concreto de persistencia a través de modelos. Gracias voy a jugar con tus sugerencias! – deanvmc