Documentos de Académico
Documentos de Profesional
Documentos de Cultura
8 - Patrones
8 - Patrones
PATRONES
INTRODUCCIÓN
El concepto de patrones se remonta a la década de los años 70, uno de sus iniciadores fue el
arquitecto alemán Christopher Alexander, quien los aplicó en el contexto de su campo
profesional. Alexander define formalmente a los patrones como:
“Un patrón describe una solución correcta para un problema frecuente, el cual debe estar
expresamente descrito, dentro del contexto en el cual será utilizado”.
Los patrones capturan la experiencia existente y probada para promover buenas prácticas.
CLASIFICACIÓN
Existen varios tipos de patrones, dependiendo del nivel de abstracción, del contexto
particular en el cual aplican o de la etapa en el proceso de desarrollo. Algunos de estos tipos,
de los cuales existen publicaciones al respecto son:
de Diseño
de Arquitectura
de Análisis
para Ambientes Distribuidos
de Negocios
de Procesos y Organizacionales
1
controladores. Pueden existir múltiples vistas del modelo. Cada elemento de la
vista tiene asociado un componente controlador.
La separación del Modelo de los componentes Vista y Controlador permite tener múltiples
vistas del mismo modelo. Si el usuario cambia el modelo el controlador debe notificarlo a la
vista para que ésta refleje los cambios. Por lo tanto el modelo notifica a todas las vistas
siempre que sus datos cambien.
Gracias a un correcto aislamiento entre el modelo de negocio (código en el lenguaje de
programación elegido) y la interfaz de usuario (los formularios) podríamos comenzar a
desarrollar la aplicación sin necesidad de tener una interfaz de usuario definida ni
terminada. Además, si la aplicación está bien diseñada no debería importar el entorno en
que se ejecute, ya sea en una aplicación Web, GUI, o línea de comandos.
Es necesario definir un nexo entre la interfaz de usuario y el modelo de negocio. Ese nexo
es el controlador (código del formulario donde se manejan). El controlador permite
centralizar la recepción de las órdenes que el usuario envía desde la vista, demandar la
ejecución de las operaciones al modelo y en base a los resultados comunicados por éste,
mostrarlos en los elementos de la vista
Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el
control generalmente es el siguiente:
El usuario actúa sobre la vista pulsando un botón del formulario, por
ejemplo.
El controlador recibe la notificación de la acción solicitada por el usuario. El
controlador gestiona el evento que llega, normalmente a través de eventos
(handler).
El controlador accede al modelo, actualizándolo, posiblemente
modificándolo de forma adecuada a la acción solicitada por el usuario (por
ejemplo, el controlador actualiza el carro de la compra de usuario llamando al
método adecuado del modelo).
El controlador delega a los objetos de la vista la tarea de desplegar la
interfaz de usuario. La vista obtiene sus datos del modelo para generar la
interfaz apropiada para el usuario donde se refleja los cambios en el modelo
(por ejemplo, produce un listado del contenido del carrito de la compra). El
controlador da la orden para que ésta actualice sus fuentes.
La interfaz de usuario espera nuevas interacciones del usuario,
comenzando el ciclo nuevamente.
EJEMPLO
En el caso de una sencilla aplicación para consultar datos de una Base de Datos suponemos
que el usuario debe indicar su nombre y su contraseña para poder trabajar.
Necesitamos 3 formularios que compondrán la capa de vista: Formulario de autentificación,
de introducción de consultas e informe de resultados.
El modelo de negocio contendrá una lista de usuarios autorizados junto con sus contraseñas,
la base de datos sobre la que efectuar las consultas y los módulos (clases o librerías de
funciones) que se encarguen de realizar las operaciones (comprobar la información del
usuario, construir la consulta, efectuar la consulta).
El controlador serviría de pegamento, recogería las órdenes y datos que el usuario enviase
desde la vista, las traduciría en operaciones del modelo de negocio y, en base a los
resultados, mostrará los resultados en uno u otro formulario de la vista.
La inclusión del controlador añade (al menos) las siguientes ventajas:
El controlador, como su propio nombre indica, controla todo el flujo de la
aplicación, esto facilita la modificación del comportamiento de la aplicación
(añadir o eliminar formularios o modificar alguna secuencia). Además de
facilitar tareas en las que sea necesario más de un formulario (Como en los
asistentes de instalación de Windows, donde existe una secuencia de
formularios, los primeros toman información para después instalar).
La separación entre controlador y vista facilita el intercambio de vistas
3
También permite crear diferentes versiones de la misma aplicación (¿Que
tal una versión en que se modifique el controlador de forma que ciertos
botones muestren el texto "No disponible en la versión de evaluación"?).
La vista, al necesitar poco o nada de código, puede ser desarrollada por un
equipo de diseñadores independiente del de programadores.
PATRÓN DE CAPAS
Microsoft utiliza el patrón arquitectónico llamado patrón de capas para plantear muchas
soluciones a problemas más o menos complejos. Este patrón nos ayuda a separar las
distintas responsabilidades de la aplicación en lo que se denomina capas. De esta forma
habrá una capa encargada de tratar con el origen de datos (bases de datos, ficheros XML.
etc), otra capa destinada a la lógica de negocio de la aplicación (utilizar esos datos obtenidos
para realizar distintas operaciones) y otra capa destinada a presentar las vistas (la parte de la
interfaz de usuario).
La estructura de capas favorecer el mantenimiento de la aplicación, la reutilización del
código y su escalabilidad.
Para conocer este patrón analizaremos un ejemplo en el que se desea desarrollar un sistema
empresarial, donde se pretende manejar la información de presupuestos para los clientes de
la empresa. Es necesario conocer los precios internos, elaborar el presupuesto, acceder al
inventario de los productos, y contemplar los datos e historia del cliente que pide el
presupuesto. La información debe estar disponible para ser consultada por la Web, y
provenir de distintas fuentes de datos.
Se pretende organizar la arquitectura del sistema para que sea flexible, por ejemplo, que
contemple las distintas formas de acceder a los datos, y las formas de procesarlos, y por
último, los distintos modos de visualizar el resultado.
4
Podemos tomar la decisión de separar la aplicación según este esquema:
Este patrón debe evitar que el cambio en una capa altere mínimamente las otras capas. La
prueba más difícil, en nuestro ejemplo, podría ser: al cambiar las fuentes de datos (las bases
de datos usadas), poco debería afectar a la capa de presentación. Y si el día de mañana
queremos incorporar una capa de presentación distinta (como un sistema de atención
automática por teléfono), no debería alterar a las otras capas ya desarrolladas.
Si bien en este ejemplo, las capas que elegimos construir son las de presentación, negocio y
datos, el patrón es lo suficientemente general para aplicarse en otras situaciones.
5
Código de la clase DAL
Imports System
Imports System.Data
Imports System.Data.Common
Imports System.Configuration
Imports System.Data.Odbc
' <summary>
' Contiene los métodos que permitirán acceder a la base de datos para
realizar las operaciones que se puedan necesitar.
' </summary>
'
Sub New()
cadenaConexion = "Driver={MySQL ODBC 5.1
Driver};Server=localhost;Database=prueba;User=root;Password=pepe;Option=3;"
conexion = CrearConexion()
End Sub
#Region "Comando"
'Crea Objeto Connection
Function CrearConexion() As OdbcConnection
Dim conn As New OdbcConnection
'Cadena de conexión
conn.ConnectionString = cadenaConexion
Try
If conn.State = ConnectionState.Closed Then
conn.Open()
6
End If
Return conn
Catch ex As Exception
MessageBox.Show("Fallo de conexión")
Return conn
Finally
End Try
End Function
#End Region
#Region "DataTable"
7
End Sub
#End Region
#Region "EjecutaNonQuery"
'Ejecuta una orden SQL
Public Sub Ejecuta(ByVal ordenSql As String)
Dim miComando As OdbcCommand
miComando = CrearComando(ordenSql) 'deja la conexion abierta
Dim i = miComando.ExecuteNonQuery() 'Se puede analizar un valor
devuelto=> el número de filas afectadas
End Sub
#End Region
#Region "DataReader"
Public Function DevolverReader(ByVal ordenSql As String) As
OdbcDataReader
Dim miDateReader As OdbcDataReader
Dim miComando = CrearComando(ordenSql) 'deja la conexion abierta
With (miComando.Connection)
miDateReader = miComando.ExecuteReader()
End With
Return miDateReader
End Function
#End Region
End Class
8
Código de la clase FORMULARIODATOS
' <summary>
' Contiene los métodos que controlan los eventos del formulario
' </summary>
'