Dos hombres viajaban por un camino; después de un gran trecho encontraron una gran montaña que tenía que subir. Uno de ellos comenzó a lamentarse, “¡¡Aaayyyy!!! Que montaña tan grande. ¿Cómo la voy a subir? No puedo, estoy cansado, es imposible. No podré.” Mientras este se lamentaba mirando la gran montaña, su compañero de viaje, con la vista puesta en el suelo, siguió su camino y antes que el otro terminase de lamentarse había llegado a la cima.
Es habitual entre los que nos dedicamos a la labor de realizar programas informáticos saltar como gatos asustados cuando un cliente nos llama para decirnos que tal o cual proceso, función o cálculo no funciona como debiera o simplemente “da un error” (o lo que es más habitual en los usuarios “el programa no funciona”).
Y digo de saltar como gatos asustados, con las uñas fuera, para asegurar al cliente que eso es imposible. Es natural, nuestros programas NUNCA FALLAN, igual que para una madre su hijo NUNCA HACE NADA MALO.
Pensaba yo en esto a raiz de que al igual que nuestros usuarios nos reportan errores y actuamos de esa forma, nosotros somos usuarios de otras herramientas programadas por otros colegas de profesión que actúan de igual forma.
Todos (yo el primero) olvidamos totalmente ponernos en el lugar de nuestro usuario y entender que si nos esta indicando un fallo es que lo está sufriendo, por mucho que seamos infalibles programando que no podamos reproducirlo o el usuario sea incapaz de refererirnos que ha hecho (por que no lo recuerda, por que no le vuelve a pasar o por lo que sea).
Dicho sea de paso que muchas de las notificaciones de usuarios molestos que nos dejan el críptico mensaje de “el programa no funciona” son errores o fallos menores desde nuestro punto de vista de programador, pero, como ya he apuntado antes, debemos ponernos en su lugar y entender el por qué de su mensaje sin saltar como gatos asustados con el pelo de la cola erizado y las uñas fuera, ya que para él, desde su punto de vista, el programa en ese momento NO FUNCIONA.
Algunos colegas de profesión me han pedido en varias ocasiones que dedique un artículo al MVC (modelo-vista-controlador) para intentar acercarlos esta Patrón de Diseño.
El MVC es un Patrón de Diseño de software por el que se intenta independizar el código en tres partes:
El Modelo, también llamado Dominio, que será el encargado de comunicarse con los datos.
La Vista, que será la encargada de comunicarse con el usuario.
El Controlador, que será el encargado de comunicar internamente al Modelo y a la Vista.
Tengamos, por ejemplo, la pulsación del botón grabar en una pantalla de edición; el evento se produce en la Vista y deberá ser redirigido al Controlador, donde se efectuarán las comprobaciones y operaciones necesarias, para posteriormente llamar al método del Modelo que se encargue de la grabación de los datos en la Base de datos.
El objetivo de este sistema es independizar las partes de nuestro código para poder reutilizarlo en otras aplicaciones fácilmente o cambiar el aspecto de la Vista.
Una vez se comprende el funcionamiento, su implementación es bastante sencilla aunque laboriosa, ya que requiere la redacción y mantenimiento de tres programas; aunque se gana en ventajas al saber que cada parte por separado funciona correctamente y puede ser reutilizada en otras aplicaciones.
Os dejo este ejemplo, realizado con Xailer Enterprise y MySQL.
Espero vuestros comentarios.
Actualización 09.05.2010: Nueva versión del ejemplo MVC con Xailer. Incluye un campo blob.
Hola, en las ultimas semanas estoy basante ocupado con otros temas para poder terminar de pulir los artículos que siguen a los dos anteriores sobre el modelo de datos. Disculpad los retrasos, en cuanto tenga un momento me pongo a ello.
Este es el segundo artículo sobre modelo de datos, en este estudiaremos las clases TFactura y TLineasFactura.
Desde la clase TFactura accederemos a objetos de las clases TCliente y TLineasFactura; y de la clase TLineasFactura accederemos a un objeto de la clase TArticulo.
Observando el código de las clases notaremos que el nivel de automatización al que se llega y que nos facilitará mucho el trabajo de codificación de nuestra aplicación.
CLASS TFactura FROM TQuery
DATA cConsulta
DATA oCli
DATA oLin
METHOD Init( cQuery )
METHOD Delete( nId_Articulo )
METHOD Change( oSender )
ACCESS oCliente
ACCESS oLineas
END CLASS
METHOD Init( cQuery ) CLASS TFactura
DEFAULT cQuery TO “SELECT * FROM cabfac”
::New()
::OnChange := { | oSender | Change( oSender ) }
::cConsulta := cQuery
::Query( ::cConsulta )
RETURN Self
METHOD Delete( nId_Factura ) CLASS TFactura
IF !Empty( nId_Factura )
::Command( “DELETE FROM cabfac “ + ;
“WHERE id = “ + Str( nId_Factura ) + “ “ + ;
“LIMIT 1” )
::Change()
END IF
RETURN Nil
METHOD Change( oSender ) CLASS TFactura
::oCli := NIL
::oLin := NIL
RETURN Nil
METHOD oCliente CLASS TFactura
IF Empty( ::oCli )
::oCli := TCliente():Init( “SELECT * FROM cliente “ + ;
“WHERE id = “ + Str( ::Id_Cliente ) )
END IF
RETURN ::oCli
METHOD oLineas CLASS TFactura
IF Empty( ::oLin )
::oLin := TLineasFactura():Init( “SELECT * FROM detfac “ + ;
“WHERE id_factura = “ + Str( ::Id ) + ” ” + ;
“ORDER BY linea” )
END IF
RETURN ::oLin
//——————————————————————-//
CLASS TLineasFactura FROM TQuery
DATA cConsulta
DATA oArt
METHOD Init( cQuery )
METHOD Delete( nId_Articulo )
METHOD Change( oSender )
ACCESS oArticulo
END CLASS
METHOD Init( cQuery ) CLASS TLineasFactura
DEFAULT cQuery TO “SELECT * FROM detfac”
::New()
::OnChange := { | oSender | Change( oSender ) }
::cConsulta := cQuery
::Query( ::cConsulta )
RETURN Self
METHOD Delete( nId_Factura, nLinea ) CLASS TLineasFactura
IF !Empty( nId_Factura )
::Command( “DELETE FROM derfac “ + ;
“WHERE id_factura = “ + Str( nId_Factura ) + “ “ + ;
“AND linea = ” + Str( nLinea ) + ” ” + ;
“LIMIT 1” )
::Change()
END IF
RETURN Nil
METHOD Change( oSender ) CLASS TLineasFactura
::oArt := NIL
RETURN Nil
METHOD oArticulo CLASS TLineasFactura
IF Empty( ::oArt )
::oArt := TArticulo():Init( “SELECT * FROM articulo “ + ;
“WHERE id = “ + Str( ::Id_Articulo ) )
END IF
RETURN ::oArt
//——————————————————————-//
Para acceder a una factura, símplemente tendremos que escribir el siguiente código:
oFactura := TFactura():Init( “SELECT * FROM cabfac WHERE id = ” + Str( nNumFac )
para acceder a los datos del cliente de una factura:
oCliente := oFactura:oCliente
MsgInfo( oCliente:Nombre )
para acceder a las lineas de la factura:
nTotal := 0
oFactura:oLineas:GoTop()
WHILE !oFactura:oLineas:Eof()
nTotal += oFactura:oLineas:Cantidad * oFactura:oLineas:Precio
oFactura:oLineas:Skip()
END DO
MsgInfo( nTotal )
para acceder al nombre de un artículo:
oFactura:oLineas:oArticulo:Nombre
Con esto terminamos el segundo artículo dedicado a la introducción al modelo de datos. En el próximo estudiaremos como ir mejorando poco a poco las estructuras de datos para, por ejemplo, poder refrescar las consultas, aplicar el uso de vistas, crear métodos que proporcionen totales, etc. Veremos como el modelo básico que hemos definido en estos dos artículos puede completarse hasta conseguir una funcionalidad tan amplia que aumentará el ahorro y claridad posterior de nuestro código.