Solución Semana 3: "Consultas de Usuarios incompleta" (II/III)

Como decía anteriormente, "hacer un sistema es un tema de orden", entonces hagamos un "mapa" para saber donde estamos parados y hacia donde vamos.

Para hacer el formulario

ConsultarUsuario -> PresentaciónFachada

Una vez que ejecutamos el módulo correspondiente el formulario de consultas queda generado a partir del template contenido_consultar_usuario.tpl.html, esperando luego a que se ingrese información y presione el botón "consultar".

Ejecutar el formulario

Estando en el formulario, luego de ejecutar el botón "consultar", se invocarían a partir del template contenido_consultar_usuario.tpl.html:

MostrarUsuario -> PresentacionFachada -> DominioFachada -> PersistenciaFachada

Bien, el tema es el siguiente: ahora tenemos más de un parámetro que recibimos por $_REQUEST (que engloba a GET y POST), lo cual podemos usar varias estrategias:

• Agregar los parámetros que necesitamos en la firma del método ejecutar y en todos los métodos que lo necesiten, capa por capa (vamos a tener además del id y nombre, la descripción).
• Colocar un genérico $_REQUEST sin parámetros, que resultará en el array completo con lo que recibamos desde el formulario. También funcionaría $_GET o $_POST. (Nota: hay que tener en cuenta la seguridad de un sistema al recibir desde el "exterior" cualquier tipo de información).
  

Usemos esta última opción:

• DominioFachada::traerObjetoUsuario( $request )
• PersistenciaFachada::traerUsuario( $request );
  

Diagrama de Secuencia

Aprovechemos para conocer como trabaja un diagrama de secuencia y para qué nos puede servir. Lo ideal es que sea parte del diseño a "bajo nivel" antes de empezar codificar, como un plan para saber exactamente como trabajará nuestro sistema y como será implementado... todos los métodos estarán definidos de antemano con sus objetos y solo deberemos posteriormente programar su contenido. En este caso, lo usaremos al revés, definir un mapa a partir de lo que existe y validar que el diseño sea correcto (por ejemplo, respetar el correcto acceso a las 3 capas).


Este diagrama está dividido en dos etapas: cuando se ejecuta por primera vez y armar el formulario de consultas, y cuando se presiona le botón de "consultar" para generar todo el proceso de búsqueda de información en la base de datos.

En la primer etapa solo podemos documentar en este caso como se invoca el template, puesto que ahí quedamos a la espera de la acción del usuario. Cabe aclarar que no necesariamente deberíamos documentar el trabajo con el sistema de templates porque se puede dar por convenido que su funcionamiento se conoce y solo se necesita explicitar el resto de la lógica.

En la segunda etapa se parte del accionar del botón de búsqueda que genera la invocación en cascada de cada método de cada clase de cada paquete, hasta obtener el resultado buscado.

Varias salvedades para tener en cuenta:

• Las flechas que aparecen en el diagrama representan las llamadas a los métodos perteneciente a cada Clase, es decir, muestran claramente el concepto de que la interfaz de los objetos son sus métodos públicos y los clientes de esos servicios son los que los invocan.
• El nivel de profundidad en la documentación dependerá de nuestro contexto, y cada comentario (en UML es el dibujo que representa una "nota" con la punta doblada) puede aclarar la parte que se toma como obvia y que no aparece en el diagrama.
• Muchos autores sugieren que no es necesario mostrar una flecha de retorno de datos (de derecha a izquierda), y menos todas las veces que sucede esta acción, puesto que lo importante es marcar el camino para generar la comunicación entre los objetos. Perfectamente podría ir al final del segundo diagrama una flecha de retorno que volviera a cada capa documentando que retorna un array con el objeto Usuario encontrado, pero podría considerarse redundante porque se supone que esto sucede.
• De la misma forma que en la parte 1 -que no es necesario documentar el Template- en la parte 2 no es necesario documentar SentenciaSQL (framework).
  

Finalmente, ya lo hemos dicho con los Casos de Uso, los diagramas son "interpretativos" y están sujetos a un contexto y a la documentación que debe acompañar siempre. Nosotros documentamos lo que queremos y esto está sujeto a un contexto y a nuestro "público objetivo".

Dudas, preguntas, en los comentarios ;-)