Explicación MVVM con WPF

[caroldev13]

Hola a todos, estoy iniciándome en WPF, actualmente desarrollo en java swing y javafx, he intentado leer varios tutoriales y verlos en vídeo, pero no soy capaz de verle la lógica, en java sigo este patrón.

MODELO:
- DTO: Donde pongo las entidades con los get y los set.
- DAO: Donde pongo las interfaces de los metodos.
- IMP: Donde implemento los metodos.

CONTROLADOR:
- Tengo controladores de las vistas donde les doy funcionalidades a los elementos de dichas vistas

VISTA:
- Los FXML donde esta el diseño.

Hay muchas cosas en común, pero no entiendo verdaderamente la forma de proceder, en los ViewModel con Inotifypropertychanged y delegatecommand, entiendo que es para desacoplar aun más, pero en un ejemplo simple me lío bastante.

Por ejemplo:

DTO: Alumno (nombre y apellido con get y set)
DAO-IMP: QUERY con metodos getAllAlumnos(), o algo similar.

Me resulta bastante complicado. A ver si me podéis ayudar a entender.

Besos Carol !!!

[agleiva]

Ok a ver... hay muuuuucho para hablar de este tema. Voy a comenzar por decir que MVVM es un patrón y NO una regla. Es decir, no hay una única manera de implementarlo y dependiendo de cuestiones de coding style, y necesidades del proyecto podes usar un approach mas purista o menos purista.

En general lo mas similar a WPF que he encontrado hasta ahora es Angular. Si conocés Angular te va a resultar fácil entender el paradigma de MVVM en WPF porque hay realmente muchas similitudes conceptuales.

Caso contrario, algunas de las principales diferencias con el modelo tradicional MVC:

- En MVVM, la vista "conoce" al VM, pero el VM no "conoce" a la vista. El VM conoce al Modelo y realiza operaciones sobre este.

- En MVVM, se usa DataBinding para conectar la vista al VM y al Model. Esta es la razon para que exista INotifyPropertyChanged.

En general yo te diria que para simplificar, siempre que puedas bindees directamente al modelo, y no al VM.

Lo mas simple que se me ocurre es esto:
- Model: Entidades con INotifyPropertyChanged
- VM: Expone instancias de entidades y los metodos para ejecutar acciones sobre los mismos.
- View: XAML + eventos que pueden llamar al VM, ya sea mediante Commands o mediante Code Behind.

Si tenes alguna pregunta mas especifica tal vez te pueda ayudar mejor

[caroldev13]

Tengo muchas preguntas, básicamente porque estoy un poco descolocada con este patrón, e intento aplicarlo correctamente. Si me ayudas a colocar las piezas que uso en java (a groso modo), se lo agradecería.

Según me expones

- En el modelo incluyo las clases con las entidades, únicamente con get y set.

- Los metodos de las entidades los declararía en el view model? es decir, queries de las bd, calculos, etc.

por ejemplo: obtenerNombrePorID();

Cuando te refieres a declarar las entidades es aplicar los get y set y el notifychanged no?

- En las vistas llamas a los métodos ya sea por codigo o por binding.

Es todo esto correcto??

Si es así, me has ayudado, solo me quedaría comprender el tema de los delegatecommand.

Muchas gracias de antemano.

Carol.

[agleiva]

Iniciado por caroldev13

Los metodos de las entidades los declararía en el view model? es decir, queries de las bd, calculos, etc.

No, en general la capa de acceso a datos deberia estar separada. Tanto con Entity Framework como con NHibernate (las 2 tecnologías de acceso a datos por excelencia en .NET) se pueden crear repositorios genéricos, con lo cual tus VMs tambien pueden ser genéricos (una enorme ventaja con respecto a java, donde los generics no sirven para nada). Es decir, tus VM invocarían a tus repositorios y éstos se encargarían de hacer las queries y guardar en la DB o en donde sea.

Iniciado por caroldev13

Cuando te refieres a declarar las entidades es aplicar los get y set y el notifychanged no?

Si, los "get y set" se llaman Properties y son otra de las grandes ventajas de C# con respecto a java.

Iniciado por caroldev13

solo me quedaría comprender el tema de los delegatecommand.

El DelegateCommand es una indireccion muchas veces innecesaria. Por eso te mencionaba el tema del grado de purismo que quieras aplicar. Los mas puristas dicen que no debe existir Code Behind en las vistas, pero esto es exagerado e injustificado en mi opinion.

El DelegateCommand se justifica si tenés varios elementos visuales que invoquen la misma acción (por ejemplo un Button y además un MenuItem dentro de un ContextMenu o algo por el estilo). Caso contrario, yo usaría code behind:

Código C#:

private void SomeButton_Click(object sender, RoutedEventArgs e) =>
    (this.DataContext as MyViewModel)?.SomeAction();
 

que es mas directo que tener que declarar un DelegateCommand en el VM para ejecutar la acción SomeAction. Me explico?

[caroldev13]

Te has explicado perfectamente, Un par de dudas respecto a la separación de acceso a datos y termina mi consulta ;).

- Se usa patrón DAO en WPF??
- Es recomendable el uso de Framework como Entity??

[agleiva]

Iniciado por caroldev13

Se usa patrón DAO en WPF??

En realidad WPF es una tecnología de presentación, y como tal no plantea ninguna cuestión relativa al acceso a datos.

Si tu pregunta es si se usa patrón DAO en C#/.NET, la respuesta es si, pero como casi todo, las prácticas en un lenguaje moderno como C# distan muchísimo de la rigidez que impone un lenguaje arcaico y terriblemente limitado como java. java pone demasiado énfasis en los llamados "patrones" porque es la única forma de compensar las enormes limitaciones del lenguaje. En C# en general se codea de forma más "natural" (esto es, sin la rigidez de los "patrones") ya que casi siempre existe una ventaja en el lenguaje que permite eliminar el uso de patrones de diseño.

Iniciado por caroldev13

Es recomendable el uso de Framework como Entity??

Si, claramente por default siempre se recomienda usar un ORM, a menos que haya una BUENA razon para no hacerlo.

[caroldev13]

Buenos días/noches, que recomienda en la actualidad, UWP, WPF o Xamarin para centrarme en lo que tenga futuro. ya que me llevara un tiempo controlarlo al nivel que tengo en java.

Besos Carol.