Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S2‎ > ‎

Clase 2 - Miércoles 24/08/2011 - Unidad2: MVC, Bindings & Arena

publicado a la‎(s)‎ 25 ago. 2011 12:26 por Javier Fernandes   [ actualizado el 25 ago. 2011 13:57 por gisela decuzzi ]

Repaso de Maven (clase anterior)

Inicialmente repasamos algo de lo que vimos la clase pasada acerca de Maven.

Aclaramos que Maven no es solo un servidor. Es una herramienta que modela el concepto de proyecto, dependencia, ciclo de vida, etc.
A diferencia de una herramienta como subversion que solo se encarga de versionar archivos, pero "archivos en general". Subversion no conoce el concepto de "proyecto", para el todos son "archivos" y ya

Se parecen en una cosa, en que Maven también tiene servidores, donde se publican los proyectos. Pero lo que se publican no son archivos sino artefactos, con su pom y sus versiones distribuibles. Por ejemplo el jar. De hecho podemos tener más cosas como el un zip con el código fuente, los javadocs, los tests, etc. Depende como configuremos Maven y qué cosas querramos publicar.

Pueden mirar su repositorio local para ver cómo es, cómo se estructura y qué contenido tienen:

$UI_HOME/data/maven/repo/

Ejemplo de archivos que puede tener un artefacto:

commons-beanutils-1.8.3-javadoc.jar

commons-beanutils-1.8.3-javadoc.jar.asc

commons-beanutils-1.8.3-javadoc.jar.md5

commons-beanutils-1.8.3-javadoc.jar.sha1

commons-beanutils-1.8.3-sources.jar

commons-beanutils-1.8.3-sources.jar.asc

commons-beanutils-1.8.3-sources.jar.md5

commons-beanutils-1.8.3-sources.jar.sha1

commons-beanutils-1.8.3.jar

commons-beanutils-1.8.3.jar.asc

commons-beanutils-1.8.3.jar.md5

commons-beanutils-1.8.3.jar.sha1

commons-beanutils-1.8.3.pom

commons-beanutils-1.8.3.pom.asc

commons-beanutils-1.8.3.pom.md5

commons-beanutils-1.8.3.pom.sha1

Los archivos. asc y .md5 contienen un checksum que permite al cliente de maven verificar que al bajarse uno de estos archivos no se haya introducido ningún error en la comunicación. Es decir que no se hayan perdido algunos bytes por ahí en el camino
Pero podemos ver:
  • jar con el javadoc (recuerden que jar = zip)
  • jar con el código fuente (sources)
  • jar del proyecto (binarios)
  • pom
Para más información, lean el apunte de maven.

Un poquito de SVN

Recordamos que el SVN es una herramienta de versionado de código. Que va manejando versiones del repositorio. Y que ante cada commit se incrementa.
Además sabe mostrarnos la historia de cambios para un archivo/carpeta dados.

Mostramos  un poquito el plugin de svn de eclipse, que nos facilita bastante las cosas, ya que el cliente de consola es bastante precario.

Si van a un archivo java, boton derecho -> Team -> Show History
Van a ver una lista de cambios publicados en el svn para ese archivo, la fecha, autor, comentario, etc.



Unidad 2


Arrancamos entonces con la Unidad 2 con una introducción de la mano de Gise.

Tiramos algunas ideas que nos vienen a la cabeza cuando hablamos de Interfaz de Usuario (UI del inglés a partir de ahora).

Diferentes tipos de controles:
  • textbox: para editar/ingresar un valor
  • label: para mostrar un texto
  • Compuestos como grillas, etc.

Layouts

Contamos la idea de que los elementos tienen que ser organizados y posicionados en la interfaz. Este proceso se llama layout. Más adelante en las siguientes clases vamos a ver las diferentes estratégias de layout con ejemplos.

Bindings

Un binding significa un "vínculo" entre un elemento de la UI y nuestro modelo (objeto de negocio desacoplado de la UI).
El concepto de vínculo es bastante poderoso. Y vamos a ver que de acuerdo a la implementación, es decir, al framework de UI que estemos usando, ese vínculo va a tener más o menos responsabilidades.

La idea del binding, y de tener un modelo detrás, es lo que nos permite darle sentido a la interfaz de usuario. Si no, solo sería una agrupación de controles.

Recordando algunos patrones

Nombramos el pattern Composite para describir un tipo de elemento de UI, que contiene otros elementos dentro. Y que de esta forma pueden ser tratados polimórficamente.
Por ejemplo, una "grilla" o tabla, que tiene elementos como filas, columnas, celdas.

También vimos que el patrón Observer/Listener se utiliza a nivel de UI, ya que es una buena forma de interacción entre el modelo y los componentes de UI.
De esta forma nuestro modelo queda desacoplado de las clases de la vista. Aunque interactúan a través de este patrón.

MVC

Luego de recordar estos patrones nos metimos a contar un poco lo que es el patron MVC.
Model, View, Controller.

La vista en nuestro ejemplo eran los controles o elementos visibles como el textbox, el botón, etc.

El usuario utiliza los controles de la vista para interactuar con la aplicación. La vista se encarga de propagar eventos como un onClick(), onBlur(), etc.
Y luego la acción a realizar ante este evento, se implementa mediante un Controlador.

Como el controlador sigue siendo un objeto acoplado a la Vista, si escribieramos nuestra lógica de negocio en los controllers, quedaría dispersa entre muchos controllers, rompiendo la idea de objetos. No tendríamos modelado nuestro negocio en objetos.

Entonces, nuestros controllers van a ser bien chiquitos, y genéricos, para poder reutilizarlos, y no tener que codificarlos para cada pantalla, para cada aplicación.

Estos controllers van a trabajar con un Modelo. Entonces, el controller vincula un control de la Vista con el Modelo. Por ejemplo, para editar una propiedad del objeto de negocio en un textbox, o para invocar un método del objeto ante un click de un botón.


Segunda Parte: MVC y bindings en Arena

Después de la intro teórica y de explicar los conceptos nos metemos a ver un ejemplo práctico y su implementación en Arena (y luego SWT).

Hablamos de arquitecturas cliente pesado (mas asociado a aplicaciones de escritorios) y cliente liviano (mas asociado a aplicaciones web).
Mencionamos que el origen de la web fue para compartir texto.

Hicimos un poco de historia y mencionamos las primeras tecnologias java
  • AWT -> Swing (que se para sobre AWT) donde ambos frameworks dibujaban por su cuenta sus propios controles. Y un poco por esto y por todas las criticas de que es demasiado lento se fue dejando de lado.
  • SWT: un framework desarrollado por el proyecto Eclipse para realizar interfaces gráficas en aplicaciones de escritorio que no usa ni awt (ni swing) y usa los componentes del sistema operativo. Donde no existe el concepto de binding a un modelo.
  • Sobre SWT se construyo Jface que le da algunas nociones de modelo y binding, de todos modos tienen cosas que uno consideraria no muy feliz.
  • Por lo cual a fines didacticos surge Arena (que se para sobre JFace y nos va a permitir hacer aplicaciones de escritorio).

Ejemplo: Conversor de Millas a Kilómetros.

Pensamos un ejemplo sencillo, convertir de millas a kilometros y pensamos en que objetos (primero de la interfaz) queriamos tener, o cómo se vería la aplicación:
Hablamos que necesitabamos:
  • textbox: el lugar donde podemos ingresar las millas.
  • label: para mostrar el resultado de la conversion.
  • button: para Convertir, la forma de decirle que realice la acción.
  • frame: el contenedor de los demas componentes.
Hablamos de la logica que necesitariamos que en nuestro caso seria la de el calculo de conversion y mencionamos algunas limitaciones si no tuviesemos el modelo desacoplado de la vista: los tests unitarios que no se podrian hacer :(

El modelo (version "0")


Nos detuvimos a pensar en el modelo de objetos y lo pensamos desde un testcase (TDD), surgio una clase "Conversor" que sabe convertir por lo que nos gustaria que entienda el mensaje convertir que espera las millas y devuelvo los kilometros.
Fuimos por ese lado:

    #Conversor >> convertir: millas
        ^ millas * 1.60934.


O en su versión Java:

public class Conversor {

    public double convertir(double millas) {
        return millas * 1.60934
    }

}

Y tuvimos algunos problemas... Quisimos hacer una correspondencia uno a uno entre nuestro modelo y nuestra vista y vimos que no lo podiamos hacer modelandolo asi. O que en realidad complicaba un poco las cosas, y aparecía un "code smell" que nos indicaba que nos faltaba una abstracción.

Veamos esta conexión
  • Frame --> Modelo: Converter
  • textbox de millas --> Modelo: nada
  • label --> Modelo: nada
  • Botón --> con un listener de "onclick" que invoca el método "convertir"

Problemas:

  • Nuestro textbox millas no estaba conectado con el modelo.
  • Lo cual hacia que al clickear convertir tuvieramos que hacer demasiadas cosas:
    • obtener las millas del objeto textbox.
    • convertir el string (que tenia el textbox) a numero (double).
    • mandar el mensaje convertir con las millas (como parámetro de tipo double).
    • el resultado convertirlo de vuelta a String y  setearlo en el label donde se muestra la conversión
Como consecuencia, nuestro controller, en este caso el listener del onClick del botón quedaba bastante complejo y hacía demasiadas cosas.

Entonces dijimos que nos gustaria tener una implementación del patrón mvc un poco más feliz, que respete las buenas prácticas de objetos. Para eso pensamos en otra solución...

Refactor: Versión "1"

Decidimos:
  • vincular las millas del textbox a una propiedad del Converter (Converter.millas).
  • vincular los kilometros del label a otra propiedad (Converter.kilometros).
  • al apretar convertir mandarle el mensaje convertir al conversor (que no devuelve nada y no recibe parametros).
La relación ahora queda:

  • textbox(millas) <---> Converter.millas
  • label(km) <--- Converter.kilometros
  • Boton <---> Converter.convertir()
Y nuestro modelo (simplificado acá) quedaría asi:

public class Conversor {

      public void convertir() {... }

     public void setMillas(double millas) {... }

     public double getKilometros() {... }

}

Bindings

Para vincular un componente de ui con un atributo de nuestro objeto usamos otro controller (binding) que actualiza el modelo.

Hablamos un poco del binding y dijimos que es como un Mediator y un Listener que esta escuchando el evento de modificacion de su componente de ui asociado (y puede ser bidireccional, hablamos del label kilometros que es un ejemplo de una interaccion de "modelo a vista").

Particularmente los bindings de Arena tienen un plus que es es saber hacer ciertas adaptaciones (por ejemplo si a un tetbox lo asociamos con una propiedad que es un double lo transforma automaticamente).

Mostramos la implementacion del Converter con arena y en el medio

Java "Beans"

Hablamos de lo que es un bean, y lo que seria el contrato de un Java Bean (NO confundir con EJB), que nos dice que tenemos que tener:
  • accesors para nuestras propiedades (getters y setters). OJO que una propiedad no necesariamente es una variable del objeto. Simplemente respeta el hecho de que entiende los mensajes getSaraza y setSaraza. Algo importante que esta bueno notar es que si tiene el getter y NO el setter esa propiedad es inmutable.
  • un constructor vacío.
Noten que respetar el contrato de Java Bean nunca implica que tengamos objetos que solo contienen datos (y getters y setters). Nuestros objetos pueden (y deberían) seguir teniendo comportamiento.


Analizamos la solucion que pudimos hacer en arena y como afecto un cambio (sacar el boton convertir y que se convierta solo al escribir en el textbox) y mostramos otra solucion de un ejemplo similar sin la separacion de Modelo-Vista-Controlador.


Arquitectura de Layers (Capas lógicas) / Tiers (Capas físicas)

En algún momento de la clase también hablamos un poco de arquitecturas e hicimos una diferencia entre Layer y tier (multi-tier architecture)
  • Layer: capa lógica ==> Estructurar la aplicacion en capas pero NO implica separacion física. Hablamos un poco de ejemplos con las capas que mas se usan, por ejemplo una aplicacion que tiene una capa de persistencia y la capa del modelo no conoce nada de esta capa
  • Tier: capa física ==> Estructurar la aplicacion e implica separacion física (las capas en distintas máquina resolviendo la comunicación entre equipos físicos)



Material Extra

  • SWT: http://www.eclipse.org/swt/
  • Tutorial de Swing: http://www.javabeginner.com/java-swing/java-swing-tutorial

Tareas para la próxima clase

  • Haber leído esta bitácora (bien si llegaron acá luego de leer todo, mal si solo scrollearon rápido sin leer, vuelvan para arriba!)
  • Importar los proyectos de arena y el conversor (mandamos por mail) y jugar un poco con eso.
  • Leer esta página que es un script de la misma clase pero desde el punto de vista de otro docente amigo que se dá en la Universidad de San Martín. Como nuestra clase no fue exáctamente igual, y por momentos nos detuvimos hablar de otras cosas, esta lectura les va a ayudar a complementar con más definiciones y ejemplos.

Comments