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: 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:
Un poquito de SVNRecordamos 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 2Arrancamos 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:
LayoutsContamos 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.BindingsUn 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 patronesNombramos 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. MVCLuego 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 ArenaDespué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
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:
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
Problemas:
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:
public class Conversor {public void convertir() {... } public void setMillas(double millas) {... } public double getKilometros() {... }}BindingsPara 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:
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)
Material Extra
Tareas para la próxima clase
|
|
|
Ejemplo de arquitectura de layers común
Ejemplo (medio malo) de arquitectura de tiers. Cada uno de los colores es una capa física diferente (máquina)