Aquí estoy tratando de responder en términos ingenuos muy simples sobre algunas de las preguntas de WPF que enfrentan los desarrolladores de principiantes/winforms y algo que enfrenté cuando comencé con WPF. Hay muchos artículos y tutoriales en Internet que brindan suficiente conocimiento, pero es difícil encontrar respuestas a preguntas muy simples. Estoy tratando de abordarlo aquí.
¿Qué es WPF?
Windows Presentation Foundation conforme avanza la expansión; es un sistema de "Presentación" para construir aplicaciones de Windows. Si usted es un desarrollador de winforms, la principal diferencia que encontraría en WPF es la apariencia del diseñador. A diferencia de winforms, el código de diseñador no es el código C# sino el código XAML.
¿Por qué WPF?
Bueno, la razón principal de que WPF sea preferible a las formas de victoria es que WPF proporciona una interfaz de usuario rica. Aparte de esto, hay muchos otros beneficios que proporciona WPF, está disponible más claramente en muchos tutoriales en Internet. Es un motor de representación basado en vectores. Si uno simplemente compara la UI de una aplicación winform y una aplicación WPF, la diferencia en términos de apariencia quedará en claro.
¿Qué es MVVM?
MVVM es un patrón, que se adapta al desarrollar las aplicaciones. Se expande como "Model View View Model", básicamente, mientras estructuramos el proyecto, tenemos una carpeta modelo bajo la cual se colocarían todos los archivos de modelo (.cs), debajo de la carpeta view model todos los archivos de modelo de vista (.cs) serían colocado y debajo de la carpeta de vista se colocarán todos los archivos de vista (.xaml). Si se usa MVVM, no habrá ningún código detrás, lo que significa que el archivo .xaml.cs no tendrá ningún código, excepto el método creado automáticamente.
Modelo: El modelo tiene la parte de lógica de negocios que admite el modelo de vista con los datos que finalmente se presentarán en la vista.
ViewModel: Cada vista tendría un modelo de vista. Viewmodel implementaría la interfaz INotifyPropertyChanged y tendría todas las propiedades vinculadas a la vista correspondiente. El modelo de vista no está cargado con ninguna lógica comercial y la responsabilidad recae en el modelo.
Ver: Ver no es más que el archivo xaml donde está diseñada la ventana. XAML es un lenguaje de marcado. En WPF, a diferencia de los winforms, cada control estaría vinculado con una propiedad de dependencia predefinida o definida por el usuario.
¿Por qué MVVM?
Cada vez que se desarrolla una aplicación en WPF, MVVM resulta útil. Una de las mayores ventajas de usar MVVM es que hace posible una prueba de unidad independiente de UI, ya que no hay código detrás durante la prueba de la unidad. No se requieren objetos relacionados con UI y, por lo tanto, es posible una cobertura de código del 100%. En la prueba de unidad, el usuario puede pasar 'comandos' (buscar comandos en wpf) para probar un caso de uso particular.
¿Es un mandato o una necesidad absoluta ir con MVVM cuando se trabaja con WPF?
Yo diría que no, no es obligatorio ir con MVVM cuando se trabaja con WPF, pero depende del requisito. Uno tiene que ver la ventaja que proporciona MVVM y luego decidir si aceptarlo o no. MVVM se suma a la complejidad durante los días iniciales de desarrollo, pero finalmente viene con sus beneficios. Si la aplicación completa está en winforms y solo se está desarrollando un pequeño módulo en lugar de una característica pequeña en WPF, entonces no sería necesario seguir MVVM, uno puede felizmente tener código detrás y obtener la rica experiencia de UI. De nuevo, lo repetiría completamente, depende del tipo de requisito.
¿Puedo tener múltiples modelos de vista para una sola vista/múltiples vistas en un solo modelo de vista?
Esta es una pregunta para la que no tengo una respuesta clara y nítida en ninguna comunidad .net. En primer lugar, como vimos que la intención principal de ir con MVVM es lograr una cobertura de código del 100%, esto hace que sea obvio que vamos a probar cada modelo de vista de forma independiente y, por lo tanto, se prueba una forma completa. Teniendo esto en cuenta, es mejor optar por un enfoque de view view de una vista. Siempre podemos comunicarnos entre los modelos de vista si es necesario usando MVVM Light Messenger o cualquier otro medio que lo facilite.
¿Cuál es la diferencia entre viewmodel y model?
Esta es una pregunta que los principiantes siempre tendrían ya que no encuentran mucha diferencia entre los dos. Aquí está la diferencia: - El modelo no es más que una clase que tiene los métodos de datos para modificar los datos, que se usarían en el modelo de vista y, finalmente, enlazarían a la vista. ViewModel solo tiene las propiedades que se vincularán a la vista. En los métodos get o set, se puede llamar a un método en el modelo para obtener los datos. De nuevo, este modelo es para este modelo de vista particular. Ahora puede decidir si realmente necesita una clase de modelo, si no hay una lógica comercial pesada, entonces puede evitar una clase de modelo y colocarla en el modelo de vista, pero el limpiador sería usar una clase de modelo.
En MVVM, ¿puedo omitir un modelo de vista o una clase de modelo para una vista?
De nuevo depende del requisito mencionado anteriormente, si no hay una lógica comercial pesada, entonces puede evitar una clase modelo y colocarla en el modelo de vista, pero el enfoque más limpio sería usar una clase modelo.
Grawk = grok + awk - gran nueva palabra – MrTelly