Guía compuesta para WPF: MVVM vs MVP

design-patterns prism (4)

Estoy confundido. Quizás podrías ayudarme :)

He estado siguiendo la guía de CAG y el patrón MVP me pareció muy natural. Supongamos que tengo un modelo listo para la interfaz de usuario (por ejemplo: implementa INotifyPropertyChanged), uso el presentador para enlazar este modelo a una vista (el presentador conoce la interfaz de la vista), manteniendo mi Code-Behind lo más pequeño posible manejando solo enlaces ( Modelo y Comandos) propiedades (o métodos) o eventos para controles que no tienen ICommand y, en este caso, se delegan inmediatamente al presentador.

Después de un tiempo, he descubierto el patrón MVVM, y hasta ahora elude a mí. Por lo que puedo decir en mi enfoque, usaría MVVM solo cuando mi modelo no esté listo para la interfaz de usuario. Pero, ¿sería más razonable mantener al presentador y solo usar un nuevo modelo? No entiendo qué pierdo con este tipo de uso. Sé que me estoy perdiendo algo, pero qué es :).
También cuando su Vista es genérica y puede manejar muchos tipos de Modelos (como en un PropertyGrid). Se recomienda utilizar ViewModel con un DataTemplate, pero en este caso, simplemente no puede crear una Plantilla para cada entidad en su Modelo, solo necesita ser investigado en tiempo de ejecución, ¿qué recomendaría?
Mientras observaba a Josh Smith hablar sobre MVVM en un screencast , tengo la sensación de que la re-exposición del Modelo en el ViewModel está violando el DRY (no se repita), ¿es realmente inevitable? Me sorprende que nadie discuta sobre esto en comparación con las llamas que están recibiendo las clases de metadatos de datos dinámicos de ADO.Net .

Espero que haya sido lo suficientemente claro

Gracias

Ariel

Ad.3. Puede parecer que se repite exponiendo el Modelo en ViewModel, pero lo que realmente hace es abstraer el Modelo, de modo que View solo conozca esta abstracción (View conozca solo con ViewModel).

Esto se debe a que los cambios en el modelo no deberían interrumpir la vista. Además, su modelo se puede implementar como muchos servicios diferentes que obtienen datos de diferentes fuentes. En este caso, no le gustaría que Ver supiera sobre todos ellos, por lo que crea otra abstracción: ViewModel.

Además de los comentarios anteriores. Me gustaría compartir algo de mi comprensión personal sobre la diferencia.

Normalmente en MVP tienes una interfaz de Vista, por ejemplo. Vista, para abstraer vistas reales y vincular datos a esas vistas reales. En MVVM, en cambio, normalmente utiliza el DataContext de una vista real, por ejemplo. Un control de usuario XAML, para hacer el enlace de datos, que es similar a la IView en MVP. Así que digamos, de manera inexacta, que la unión es similar en ambos patrones.

La principal diferencia está en la parte Presenter vs ViewModel. Un modelo de vista es muy diferente a un presentador, que es un puente para intercambiar datos entre la interfaz de usuario y el modelo. En realidad, es, como su nombre significa, un modelo de la vista. Los datos expuestos en un ViewModel son principalmente para el proceso de IU. Así que, según tengo entendido, en MVVM, el ViewModel es una abstracción de vistas. Por el contrario, MVP utiliza principalmente la vista IV para vistas abstractas. Normalmente, hay pocas capas en MVVM que MVP y, por lo tanto, puede escribir menos código para hacer el mismo trabajo en MVVM:

MVVM: Modelo - ViewModel (representa vistas reales, es decir, UI) - Vistas reales

MVP: Modelo - Presentador (un puente para intercambiar datos entre el modelo y la interfaz de usuario) - Vista (representa las vistas reales, es decir, la interfaz de usuario) - Vistas reales

La ventaja de MVVM sobre MVP se basa principalmente en las siguientes 2 excelentes características de los productos de Microsoft:

Comandando en WPF. Podría estar disponible en Silverlight en el futuro, aunque ya hay algunas implementaciones que no están en el tiempo de ejecución de Silverlight.
DataContext en WPF y Silverlight.

Con respecto al # 3, muchas personas usarán el argumento "otra capa de direccionamiento indirecto", diciendo que los cambios en el modelo no afectarán la vista. Si bien esto es técnicamente correcto, no es la verdadera razón para hacer algo como esto.

Si considera el Modelo como las entidades de las que recibe un retorno, por ejemplo, una capa de acceso a datos o un servicio (que es lo que generalmente se considera), comienza a ver por qué necesita un ViewModel. Un ViewModel está diseñado para extender el modelo con los comportamientos que la Vista necesita .

Por ejemplo. Si desea poder cambiar una propiedad y hacer que la Vista sea notificada de este cambio a través del enlace, la propiedad debe elevar algún tipo de NotifyPropertyChanged para que la vista pueda reaccionar. Este es el comportamiento que tu modelo típico no tendrá.

En otro ejemplo, supongamos que tiene una colección y desea marcar cada elemento de la colección con un valor booleano cuando un usuario hace clic en una marca de verificación junto a ese elemento en la vista. Necesitarías una propiedad "IsSelected", probablemente. Este es un comportamiento que el modelo no debería proporcionar.

Sin embargo, veo de dónde viene ... Definitivamente tuve un problema con esto al principio. La primera vez que copié y pegué el contenido de un modelo en mi modelo de vista, mi estómago se revolvió, pero solo tienes que hacer las paces con el hecho de que para que tu Vista funcione, va a necesitar este comportamiento adicional que un Modelo debería tener. no proporcionar

No importa qué tan no esté en DRY, forzar los tipos WCF o LINQ a los tipos SQL (o cualquiera que sea su ORM favorito) para implementar INotifyProperyChanged es peor.

Si el presentador conoce la interfaz de la vista, necesita que todas las vistas utilizadas por un presentador tengan la misma interfaz o hacer un presentador para cada vista. Con MVVM, la vista es consciente de viewModel, y viewModel es consciente del modelo (pero no viceversa). Esto significa que varias vistas pueden usar una máquina virtual y varias máquinas virtuales pueden usar un modelo.

No estoy muy seguro de lo que estás preguntando en tu segundo punto. La máquina virtual no es la vista (o es consciente de las vistas) y para mí una plantilla de datos define cómo se muestra un objeto. Puse mis DataTemplates en un ResourceDictionary que definitivamente pertenece a la vista. Los únicos bits de "cosas" de WPF en mi capa de VM son Comandos.

Necesito un poco más de información para responder tu 3er punto. Quizás se responda solo si profundizas un poco más en MVVM.

Aquí hay una publicación mía relacionada que podría ayudarte.

Buena suerte.