Está en la página 1de 9

8.

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

PATRÓN MODELO-VISTA-CONTROLADOR (MCV)


El MCV es un patrón de arquitectura. Los patrones de arquitectura expresan el esquema
fundamental de organización para sus sistemas de software, representan el nivel más alto en
el sistema de patrones.
El MCV fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80.
MCV divide una aplicación interactiva en 3 áreas:
 Modelo (Model). Encapsula los datos y las funcionalidades. El modelo es
independiente de cualquier representación de salida y/o comportamiento de
entrada. El código del Modelo da significado a los datos; por ejemplo,
calculando si hoy es el cumpleaños del usuario o los totales, impuestos o
portes de un carrito de la compra. Es el equivalente a la lógica de negocio.
 Controlador (Controller). Reciben entradas, usualmente como eventos y
codifican los movimientos o pulsaciones de botones del ratón, pulsaciones de
teclas, etc. Los eventos son traducidos a solicitudes de servicio (service request)
para el modelo o vista. Los controladores enlazan la vista con el modelo.
 Vista (View). Muestra la información al usuario, es lo que se corresponde
con la interfaz gráfica. Obtiene los datos del Modelo por medio de los

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.

Diagrama de clases de MVC


2
Este patrón es muy popular y ha sido trasladado a una gran cantidad de entornos y
frameworks entre los que se encuentran: WinForms, ASP.NET etc. Las herramientas de
programación visual como Visual Studio .NET también siguen este esquema.
Algunos de los beneficios de este patrón son:
 Desacopla las vistas de los modelos
 Cada elemento del patrón está especializado en su tarea (la vista en mostrar
datos al usuario, el controlador en las entradas y el modelo en su objetivo de
negocio).
 Las vistas proveen mayor flexibilidad y agilidad
• Se pueden crear múltiples vistas de un modelo
• Se pueden crear, añadir, modificar y eliminar nuevas vistas
dinámicamente
• Las vistas pueden anidarse
• Se puede cambiar el modo en que una vista responde al usuario sin
cambiar su representación visual
 Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos
y canales.
• Una vista para cada dispositivo que puede variar según sus capacidades.
• Una vista para la Web y otra para aplicaciones de escritorio
 Más claridad en el diseño
 Facilita el mantenimiento
 Mayor escalabilidad

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.

MCV y WINDOWS FORM en VISUAL BASIC .NET


En VISUAL BASIC.NET el modelo MCV tiene el siguiente reflejo:
 la vista está implementada en los formularios
 el controlador se encuentra en los ficheros de los respectivos formularios
 el modelo se encuentra en todas las clases que realicen operaciones con los
datos ya sea de entrada o de salida.

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.

ESTRUCTURA DE CAPAS DE UNA APLICACIÓN EJEMPLO


La aplicación a analizar contiene un sencillo formulario que permite mostrar el contenido
parcial de una base de datos que contiene información de los gatos de una asociación de
protección de animales.
La clase DAL es la clase de acceso a la base de datos
La clase Fachada es la clase que sirve de modelo y de enlace entre la capa DAL y el
controlador de eventos FormularioGatos.
La clase FormularioGatos es la clase controlador del formulario FormularioGatos que se
corresponde con la capa Presentación

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>
'

Public Class DAL

Private cadenaConexion As String


Private conexion As OdbcConnection

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

'Crea un Comando que contiene la conexión y una orden Sql


Function CrearComando(ByVal ordenSql As String) As OdbcCommand
Dim cmd As New OdbcCommand
cmd.Connection = CrearConexion()
cmd.CommandText = ordenSql
'serán órdenes sql en formato cadena
cmd.CommandType = CommandType.Text
Return cmd
End Function

'Crea un objeto DataAdapter que permite rellenar un DataSet o un


DataTable
Function CrearAdapter(ByVal ordenSql As String) As OdbcDataAdapter
'Creo un objeto command que tiene una conexión
Dim miComando As OdbcCommand = CrearComando(ordenSql)
'Creo un objeto Adapter que me permitirá crear un DataTable
Dim miDataAdapter As New OdbcDataAdapter(miComando)
Return miDataAdapter
End Function

#End Region

#Region "DataTable"

'Crea un DataTable a partir de una orden sql


Public Function CrearDataTable(ByVal ordenSql As String) As DataTable
Dim miDataTable As New DataTable
Dim miDataAdapter As New OdbcDataAdapter

'Creo un objeto DataAdapter


miDataAdapter = CrearAdapter(ordenSql)
'Rellena el DataTable con el objeto DataAdapter
miDataAdapter.Fill(miDataTable)
'Cierra la conexion
conexion.Close()
'Devuelve un dataTable
Return miDataTable
End Function

'Actualiza la base de datos con las modificaciones del DataTable


Public Sub ActualizarDataTable(ByRef miDataTable As DataTable, ByVal
ordenSql As String)
'Creo un objeto command que tiene una conexión
Dim miComando As OdbcCommand = CrearComando(ordenSql)
'Creo un objeto Adapter que me permitirá crear un DataTable y
mantiene con él un enlace
Dim miDataAdapter As New OdbcDataAdapter(miComando)
Dim miCommadBuilder As New OdbcCommandBuilder(miDataAdapter)
miDataAdapter.Update(miDataTable)
'Cierra la conexion
conexion.Close()

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

Código de la clase FACHADA


' <summary>
' Contiene los métodos que permitirán comunicar el controlador de ‘eventos
con los accesos a la base de datos.
' </summary>
'

Public Class Fachada

Private Shared miDal As New DAL()

' Carga el control DataGridView con un BindingSource en funció de una


'orden Sql dada.
Public Overloads Shared Sub CargarControl(ByRef miBinding As
BindingSource, ByRef miGridView As DataGridView, ByVal ordenSql As String)
miBinding.DataSource = miDal.CrearDataTable(ordenSql)
miGridView.DataSource = miBinding
End Sub

'Actuliza la tabla en la base de datos en función de las modificaciones


realizadas
Public Shared Sub ActualizarTabla(ByRef miBinding As BindingSource,
ByVal ordenSql As String)
miDal.ActualizarDataTable(miBinding.DataSource, ordenSql)
End Sub
End Class

8
Código de la clase FORMULARIODATOS
' <summary>
' Contiene los métodos que controlan los eventos del formulario
' </summary>
'

Public Class FormularioDatos

' Al cargar el formulario se carga el control DataGridView con todos


' los registros de la clase gatos.

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As


System.EventArgs) Handles MyBase.Load
Dim aux As New DAL()
Fachada.CargarControl(BindingSource1, DataGridView1, "SELECT * FROM
Gatos")
'Fachada.CargarControl(BindingSource2, DataGridView2, "SELECT
gatos.nombre,razas.raza FROM gatos LEFT JOIN razas ON gatos.raza =
razas.id")
End Sub
' Actuliza la base de datos en función de los cambios realizados

Private Sub ToolStripBtnActualizar_Click(ByVal sender As System.Object,


ByVal e As System.EventArgs) Handles ToolStripBtnActualizar.Click
Fachada.ActualizarTabla(BindingSource1, "SELECT * FROM Gatos")
End Sub
End Class

También podría gustarte