MVVM o MVC? Quiere usar el mismo conjunto de clases para WPF y ASP.NET

Soy un novato en términos de patrones de diseño. Acabo de comenzar a aprender MVC cuando escucho un nuevo zumbido, MVVM.

Quiero aprender las ideas de ambos al rediseñar un inventario antiguo y una aplicación de facturación que desarrollé para un cliente. Quiero escribir una aplicación WPF basada en Windows y una versión web. Quiero usar el mismo conjunto de clases si es posible, si no, al menos con poca modificación.

Leí un par de artículos, pero no sigo la arquitectura y los conceptos de alto nivel de .NET 3.5 y 4 discutidos allí. Quiero avanzar paso a paso diseñando solo lo que realmente necesito en mi proyecto de la vida real.

¿Hay alguna referencia fácil paso a paso para MVVM? ¿MVVM es un superconjunto o un subconjunto de MVC? ¿Qué patrón es moderno y cuál debo elegir para las versiones Windows y Web de mi aplicación?

Hay ciertas clases que rara vez necesito conectar con la Vista. En ese caso, diseñar la misma clase en la forma MVVM demostrará ser una labor adicional.

¿Hay alguna referencia fácil paso a paso para MVVM?

Sí hay. Echa un vistazo al aquí.

¿MVVM es un superconjunto o un subconjunto de MVC?

MVVM pertenece a la familia MVC, por lo que, si puedes decir eso, es un subconjunto. Es una variante para desacoplar la interfaz de usuario de la lógica de negocios subyacente. Lo describiría como un hermano de MVC. Desde los primeros días de la OOP, las personas han estado buscando formas de desacoplar la IU de su lógica. MVC fue el primer arquetipo que evolucionó. Es bastante simple, aunque la mayoría de las personas no lo hacen bien. La vista es solo un observador del modelo y lo llama cuando es necesario. El controlador es solo una estrategia para que la vista se comunique con el modelo, por ejemplo, cuando necesita un comportamiento intercambiable (es decir, ReadonlyController, AdminController). MVC tiene mucho éxito y es realmente una buena práctica aplicarlo.

MVVM es un tipo especializado de patrón MVP, como lo describe Martin Fowler . MVP intenta mantener la vista lo más tonta posible (sin dejar de recibir los comentarios del usuario, etc.), mejorando así la capacidad de prueba. Su objetivo es una abstracción de la vista y la lógica de interacción que se debe poner en el presentador. El presentador solo se comunica con el modelo / lógica empresarial y actualiza la Vista. Martin Fowler describe MVVM más o menos en su Modelo de modelo de presentación.

La vista se abstrae completamente en un ViewModel. Cuando Viewnecesita una propiedad, también ViewModelnecesita tenerla. Se supone que (el ViewModel) es completamente independiente de la tecnología UI subyacente, una abstracción. Para comunicarse entre View y ViewModel, se debe utilizar un patrón de sincronización (es decir, Observer). Esto no es fácil de lograr en un entorno web sin estado. MVVM difiere de MVP, ya que la Vista ya no se une a la lógica de su modelo / negocio, sino a un ViewModel.

¿Qué patrón es moderno y cuál debo elegir para las versiones Windows y Web de mi aplicación?

El modelo de presentación (similar a MVVM) en teoría debería ser completamente independiente de la tecnología UI en uso. Sin embargo, el aspecto de sincronización necesita ser cubierto. Se puede hacer fácilmente enlazando comandos y propiedades con WPF, donde el pegamento de sincronización ya está presente. Con ASP.NET, esta es una historia diferente. Sin embargo, hay un artículo sobre CodeProject que usó el Modelo de modelo de presentación con todas las tecnologías de IU de Windows. Echar un vistazo.

Debido a problemas con el ciclo de vida y la necesidad de mantener el estado entre las publicaciones de la página, le resultará muy difícil reutilizar el 100% de su código de interfaz de usuario sin conexión entre la web y WPF. Asp.net no tiene el poderoso enlace de datos que se necesita para MVVM, también mucha de la lógica necesita ejecutarse en jscript en estos días ya que la gente espera que la UI se actualice sin la necesidad de una devolución de datos.

Si pudieras usar SilverLight, tu vida sería mucho menos compleja :-)

Del mismo modo, ¿puede alojar un navegador web en su aplicación WPF para los bits comunes de la interfaz de usuario?

Su intención de usar las mismas clases para la interfaz de usuario basada en ASP.Net y WPF no es muy práctica. El enlace de datos y el uso de javascript en la web es muy diferente al de WPF. La única opción que se me ocurre es MVP con vista completamente pasiva . En teoría, puede tener el mismo presentador que llena una página web y WPF.
En la práctica, desarrollaré una arquitectura en la que la mayoría de las reglas comerciales se encuentren en una capa de servicio web y dos niveles de presentación diferentes con la menor cantidad posible de reglas comerciales que hable con este servicio web.