martes, 18 de noviembre de 2014

Model View - View Model (MVVM) una explicación sencilla Parte I

Artículo para: Programadores de C# de cualquier nivel

Llevo algún tiempo ya en esto del WPF (unos 4 años) y veo cada vez más malos ejemplos de cómo se programa en esta maravillosa tecnología de Microsoft, que nos lleva a otro nivel en cuanto a interfaces gráficas se refiere.

En lo que a este tema se refiere, Microsoft da unas pautas MUY CLARAS de cómo operar y cómo realizar los desarrollos en esta tecnología, pero parece ser que la gente que viene de Windows Forms no desea adaptarse. Es por ello por lo que escribo este artículo, en pro de ayudar a quien quiera escucharme y siempre buscando un consenso en cuanto a desarrollo de aplicaciones de escritorio y aunque el futuro de Silverlight es muy oscuro, espero que aquellos que programéis aún en esta plataforma os sea también de ayuda.

Este artículo está dividido en 5 partes, porque el modelo MVVM no es trivial y bien requiere de un poco de tiempo para digerirlo correctamente. Si vienes de Windows Forms y estás pensando que puedes hacer lo que siempre has hecho (trabajar por eventos), estás en lo cierto, pero la estás cagando considerablemente. Si haces una aplicación WPF por eventos que tenga más de dos vistas, demuestras que no sabes del tema demasiado; tómate un tiempo para comprender y para ponerte al día, que de verdad, no cuesta nada.

El axioma para todo esto: LOS EVENTOS SON MALOS, no los uses como siempre lo has hecho. Esta tecnología no está pensada para el click de un botón o para el text_changed de un cuadro de texto, cambia tu mentalidad y empieza a pensar un poco más allá.

Y ahora el "quid" de la cuestión: ¿Cómo funciona ésto? La tecnología Windows Presentation Foundation de Microsoft tiene un "modus operandi" muy curioso, que nos permitirá explotar al máximo la capacidad de nuestras tarjetas gráficas modernas. No siendo aplicaciones de tipo videojuegos, las aplicaciones WPF pueden ser tan preciosas y tan bien diseñadas que nos sintamos como jugando con ellas; como programadores este tiene que ser nuestro objetivo final: el usuario se ha de sentir MUY cómodo usando nuestras herramientas de software.

El patrón MVVM consiste en unas buenas prácticas que yo, como experimentado programador de esta tecnología definiría de la siguiente manera (aunque como todo, es discutible):

  • Separar la vista de la funcionalidad que da soporte a la misma (a esto lo llamamos View)
  • Crear una capa que sea la interlocutora entre el negocio y la vista (que se llama View Model)
  • Por último, hacer una capa de negocio que NO TENGA NADA QUE VER con la vista (lo has adivinado, el Model).

MVVM conceptualmente
Enlaces prohibidos: desde el Model está TERMINANTEMENTE PROHIBIDO conectar con la View.

Entonces, ¿Cómo se comunican las distintas entidades en este modelo? Es muy sencillo:

  • El usuario comunica directamente SOLO con la View.
  • La View comunica directamente SOLO con el View Model.
  • El View Model hace de interlocutor entre la View y el Model.
Para ello, desde Visual Studio crearemos una solución en blanco y haremos lo siguiente:
  • Crearemos una nueva solución en blanco en Visual Studio:

  • Crearemos un nuevo proyecto de WPF, el cual será la View.



  • Crearemos un nuevo proyecto de Librería de Clases, el cual será el View Model.



  • Crearemos uno o más proyectos (normalmente son varios), de tipo Librería de Clases, los cuales en su conjunto crearán el Model.



Después de toda la operativa, nos debería quedar de la siguiente manera el árbol de proyectos:


¿Cómo relacionarlos?

  • El proyecto View referenciará al View Model. Nunca tendrá referencias al Model.
  • El proyecto View Model referenciará a uno o varios proyectos del Model. Nunca tendrá referencias al View (o tendríamos el problema de la referencia circular).
  • Los proyectos del Model NUNCA referenciarán ni a la View, ni al View Model.

Con las relaciones definidas, la comunicación solo se produce en un solo sentido:
Sentido de la comunicación por referencias a proyectos
Si bien esta comunicación es muy buena, no es suficiente porque necesitamos mecanismos para poder informar al resto de componentes en el otro sentido. En un próximo artículo os explicaré los eventos personalizados y un sencillo sistema gestor de Weak Events.

Pero antes de abordar temas más complejos, en el siguiente artículo os explicaré los XAML's y los bindings, que es algo vital en todo este asunto.

Espero que os haya gustado esta pequeña introducción y también espero sinceramente vuestros comentarios, que serán bienvenidos y de los cuales se aplicarán las correcciones que considere oportunas.


C# y Programación

miércoles, 5 de noviembre de 2014

La importancia de NO reinventar la rueda... Reto de programación #2

Artículo para: Programadores de C# de cualquier nivel




Hace unos días me encontré con un código muy similar al que arriba podéis ver... Supongo que sería por el agotamiento del que últimamente sufro, o porque no esperaba semejante maquiavélica creación, pero el hecho es que tardé unos segundos (de hecho bastantes) en entender qué demonios hacía esto.

Tras un concienzudo análisis deduje que el objetivo final que perseguía su creador no era más que hacer que un objeto DateTime que provenía de la fecha actual traída con el utilísimo DateTime.Now se convirtiera en un string para pintarlo en pantalla.

No entro a debatir de la calidad profesional de la persona que inventó semejante monstruosidad, no me interesa quejarme de gratis máxime teniendo en cuenta que TODOS (yo el primero) la cagamos alguna vez en esta profesión; pero lo que sí quiero decir es que si navegamos 3 segundos por internet nos damos cuenta que esta no es ni de lejos la manera más óptima. 

Mis razones, aunque habrá millones más son las siguientes:
  1. Cada llamada a DateTime.Now tiene un sobrecoste totalmente inútil y absurdo, además, de la primera llamada a la última aunque sea pequeña, habrá una diferencia horaria por motivos obvios (en cada llamada la foto es diferente aunque difiera en milisegundos, solo hay que conocer la propiedad Now).
  2. El operador de concatenación ("+") es brutalmente lento y desaconsejable para una concatenación tan extensa, para eso existe StringBuilder (uno de los consejos del curso oficial de Microsoft que recientemente he hecho).
  3. Este código no es para nada legible. Insisto, mi experiencia de más de 9 años no me ha permitido entenderlo hasta un análisis concienzudo, así que imagino un chavalejo que se encuentre por primera vez luchando con un dragón como éste. Nuestro código ha de ser lo más entendible posible.


La mejor manera es la siguiente sin duda, aunque muchos ya habréis llegado a ella hace un buen rato:


Nótese que ambas hacen EXACTAMENTE LO MISMO, pero la segunda es infinitamente más rápida que la primera. Esto significa que en una aplicación de alto rendimiento, si no tenemos en cuenta cosas tan básicas como ésta, es muy posible que los tiempos de respuesta sean penalizados terriblemente.

Por eso insisto, no reinventemos la rueda que no es necesario. El principio del programador vago, que explicaré en otro artículo posterior, tiene que ser lo que rija nuestro día a día... si hacemos "ciencia" o más bien, "brujería" como ésta lo más probable es que alguien pase con la excavadora y elimine nuestro código.

Quisiera comentarios y otras vivencias similares vuestras...

C# y Programación

 

Webs amigas:

  • Copyright © Los vericuetos .NET 2015
    Distributed By My Blogger Themes | Designed By Templateism