¿Cuáles son los principales inconvenientes de utilizar Presentation Model en el código?

Question

estoy tratando de prepararme para ser desafiado con la pregunta: "¿Por qué no puede simplemente implementar el modelo de presentación en el código detrás"

De hecho, he trabajado en un proyecto en el que usamos un modelo de presentación que se implementó en el código subyacente. Funcionó bastante bien, incluso pudimos ejecutar pruebas unitarias en él. Sí, tienes una dependencia de WPF en tus pruebas de unidad ... ¡pero funciona!

¿Cuáles son, entonces, los principales inconvenientes del uso de código?

Prefiero la idea de un ViewModel independiente (MVVM) pero por el momento no me siento capaz de justificarlo ante los clientes.

Answer 1

Respondió la primera parte de su pregunta, teniendo que iniciar una aplicación wpf durante la prueba unitaria. La otra es la portabilidad, ¿desea poder adjuntar implementaciones de vistas diferentes en el mismo modelo de presentación? (Débil, lo sé, pero es todo lo que tienes)

También la separación del conjunto de habilidades, solo los desarrolladores que conocen xaml estarían involucrados en la creación real de la vista. Permitiéndole utilizar exisitng en el talento de la casa que no sabe wpf.

Answer 2

La respuesta directa es principle of separation of concerns. Por supuesto, alguien podría argumentar que al colocar el modelo de presentación en el código subyacente, está separado de la vista (XAML), pero no estoy de acuerdo con eso. El código subyacente puede "ver" todos los detalles internos de la Vista porque es la Vista. Tanto el xaml como el código subyacente se compilan juntos en una clase para convertirse en la Vista. No están separados en absoluto.

Hay muchos ejemplos en los que tiene que ir al código subyacente para hacer cosas relacionadas con la vista, como conectar interacciones entre controles que no puede especificar en Xaml. Una vez que haces eso, ahora tienes tu lógica de vista entremezclada con tu lógica de presentación.

El concepto de un ViewModel es bastante poderoso. Los ViewModels pueden "hablar" entre ellos sin que las Vistas se "hablen" entre sí, o incluso sin que ViewModels "sepa" algo sobre las vistas.

Answer 3

Mire estos dos videos para tener una idea. Ambos videos muestran aplicaciones en desarrollo que comienzan con todo en el código subyacente y luego se refactorizan al patrón MVVM.

• Mike Taulty's series of videos (de hecho hay 10 videos en total, compruebe al menos primero y segundo)
• Jason Dolinger on Model-View-ViewModel

También, ver esta cuestión de forma para más enlaces: MVVM: Tutorial from start to finish?

Answer 4

se se convierte en un inconveniente cuando utiliza ViewModel-First enfoque. donde en su aplicación principal crea una instancia de su gráfico de objetos ViewModel, asígnelo al contexto de datos de la vista raíz y luego deja que la vista represente su elemento secundario relacionado en función de la notificación de ViewModel.

¿Por qué es un inconveniente? el hecho de que puede utilizar su código, pero terminará con un bounch de tricks y en algún momento debería forgot your application security. Pero en realidad este enfoque es el ideal, donde su modelo de vista es totalmente ignorante, incluso usted puede revertir su proceso de desarrollo por programa primero - piel posterior. (bromeando)

en el otro lado si utiliza Vista-Primero enfoque, entonces no habrá ningún inconveniente, porque viewmodel se sienta en él. porque controle aún en la Vista si necesita algo complicado como usar el cuadro de contraseña, simplemente haga eso naturalmente, como lo que Microsoft nos ha destinado ...

Espero que ayude.