06.01.09
Posted in Arquitectura, Patrones at 11:28 pm by Miguel
En la sección de patrones de diseño inauguramos los patrones de Ajax, con la descripción del patrón: Refresco Periódico.
El patrón viene a describir la solución a un problema común y que parte de una de las principales limitaciones de la soluciones web, la uni-direccionalidad de la relación cliente-servidor. La parte cliente es la que siempre toma la iniciativa ante cualquier transacción, por lo que si en las situaciones en las que queremos mostrar un aviso de cuándo un proceso de cálculo complejo que se ha lanzado de forma asíncrona ha terminado, o cuando por ejemplo a los usuarios autenticados en nuestra aplicación queremos mostrarles un aviso de que se ha recibido stock de un determinado producto, no tenemos más remedio que utilizar diferente estrategias, siempre por parte del cliente, para “engañar al usuario”.
Una de las soluciones a este típico problema es el uso del Patrón del Refresco Periódico, que a grandes rasgos consiste en realizar llamadas periódicas a través de ajax al servidor, para ir solicitando el refresco del estado de la información que necesitamos consultar. Como al utilizar ajax la página no se refresca de forma completa, la experiencia de usuario da como resultado algo bastante similar a lo que puede aportar una aplicación de escritorio.
Más información en http://ajaxpatterns.org/Periodic_Refresh
Saludos.
Miguel.
Permalink
04.15.09
Posted in Humor, Patrones at 10:31 pm by Miguel
Este patrón de diseño sobrepasa lo técnico, incluso lo funcional, quedándose en el ámbito representado por una persona con conocimiento funcional, que en su día tuvo algún conocimiento técnico y que ahora mismo se dedica a la acción comercial.
También lo aplican otros perfiles, muchos veces en el ámbito de la consultoría, que para preparar sus documentos funcionales y las estimaciones no tienen en cuenta u obvian los conocimientos técnicos necesarios para hacer valoraciones realistas.
Es muy sencillo de aplicar, ante cualquier problema, el sujeto aplicará el patrón de formas similares a esta:
Requerimiento funcional 1
Una vez la información asociada al cálculo infinitesimal necesario para calcular una parábola alrededor del universo conocido haya sido introducida en el modelo de datos de la aplicación actual, podrá ser exportada en el formato xml definido por la corporación e integrado en el módulo de sap activo.
Aplicación del Patrón
No hay problema, será tan sencillo como seleccionar el cálculo, botón derecho, y hacer click en “migrar”, estará listo en dos jornadas.
Requerimiento Funcional 2
El diagrama almacenado en un archivo de imagen jpg, y que muestra la información de un gráfico de barras que representa los beneficios de los anteriores 10 años de actividad de la empresa, será transformado y la información mostrada en imagen pasará a formar parte del modelo de datos de la nueva aplicación de la empresa.
Aplicación del Patrón
No hay problema, seguro que extraer la información del jpg es muy sencillo, será tan sencillo como seleccionar el fichero de la imagen, pulsar botón derecho y hacer click en “transformar imagen”.
Ánimo a todos los que disfrutais construyendo cosas!
Saludos.
Permalink
05.20.08
Posted in Patrones at 10:43 pm by Miguel
“Dícese del abuso del Patrón de Diseño Singleton en una aplicación”.
Catalogado como Antipatrón de diseño en Wikipedia.org
Lo que no veo explicado por ningún lado cuándo se puede considerar que se está abusando…
Saludos.
Miguel.
Permalink
04.30.08
Posted in Java, Patrones, Programación at 9:40 am by Miguel
Me hace mucha gracia el nombre de este Patrón de Diseño, “Memento”, inavitablemente me recuerda siempre a la película.
Memento nos ayuda por ejemplo a resolver la típica problemática de máquina de estados, donde necesitamos almacenar cuáles han sido los diferentes estados que ha tenido un objeto a lo largo de un tiempo determinado.
Un ejemplo muy cercano a todos nosotros es el uso del “Undo / Deshacer” (CTRL+Z) del que disponen la mayoría de procesadores de texto, entornos de desarrollo… y que nos permite en un momento dado poder deshacer todos los últimos pasos que hemos llevado a cabo. Para hacer esto alguien se habrá tenido que acordar de lo que habíamos hecho antes, y ese alguien es el Patrón Memento.
Os dejo link a la wikipedia
http://es.wikipedia.org/wiki/Memento_(patr%C3%B3n_de_dise%C3%B1o)
Y un link a un PDF donde tenéis una descripción más ampliada, además de un ejemplo de codificación en Java.
http://www.freewebz.com/amanecer/personal/papers/paper.memento.pdf
Un saludo.
Miguel.
Permalink
03.10.08
Posted in .NET, Patrones, Programación at 9:41 pm by Miguel
Uno de los problemas que nos podemos encontrar a la hora de ir añadiendo métodos a nuestros DAO es que el número de métodos que realizan consultas se dispare.
Por ejemplo, podemos tener un CocheDAO que permita operaciones de inserción, actualización y borrado, y además una serie de métodos que nos permitan hacer consultas sobre el mismo. Los métodos serían algo del estilo de:
GetCochesByMarca
GetCocheByMatricula
GetCochesByMarcaAndKilometraje
GetCochesByPais
La lista, interminable, únicamente limitada por la capacidad del cliente de pedir información.
Esto al final se vuelve un poco locura, el número de métodos y el trabajo que lleva realizar cada uno de ellos se puede elevar hasta el infinito. ¿Existe solución?
Parece que sí, si no, no estaríamos aquí 
Una solución al respecto es la de disponer de un único método que sea capaz de devolver resultados para cualquier consulta planteada, pero, ¿cómo conseguirlo?
Ejemplo:
public CocheFilterDTO GetCochesByFilter(CocheFilterDTO filtro)
{
}
Este va a ser el método mágico que devolverá cualquier tipo de petición. El truco está en el parámetro que recibe, que en lugar de ser un DTO común es un FilterDTO. La propiedad principal que definimos en un FilterDTO es la de que todas las propiedades que la componen son propiedades nullables (hemos hablado ya de nullables en otro post anterior). Es decir, podemos establecer con el valor null cualquiera de las propiedades definidas en el mismo.
La idea feliz se basa en que sólo vamos a filtrar por los valores del FilterDTO que no vengan a null. Por lo que si tengo en el FilterDTO una propiedad por cada uno de los elementos de filtro, voy a poder filtrar por todas y cada una de las combinaciones posibles. Sólo tengo que dar un valor a la propiedad y el método se encargará de filtrar. Si el valor está a null el método obviará el filtro por esa propiedad.
¿Cómo hacer esto? Muy sencillo, la condición SELECT que se llevará a cabo trabajará de la siguiente manera:
SELECT COCHE_CODIGO, COCHE_MATRICULA, MARCA_CODIGO, COCHE_KILOMETROS
FROM COCHE
WHERE (COCHE_CODIGO = @CodigoCoche OR @CodigoCoche IS NULL) AND
(COCHE_MATRICULA = @Matricula OR @Matricula IS NULL) AND
(MARCA_CODIGO = @Marca OR @Marca IS NULL) …
Teniendo en cuenta que todo lo que empiezan por @ son los valores que vienen en el FilterDTO… ya tenemos la solución al problema. Si el valor viene en el parámetro se filtrará por él, si no viene se compará con NULL y dará true, por lo que será como si no se haya filtrado por esa característica.
Entonces el chiste se resume en proveer al FilterDTO de todos los elementos que pueden venir o no rellenados y de definir la SELECT que trabaje con el mismo.
Idea feliz
Saludos.
Miguel.
Permalink
03.01.08
Posted in Patrones at 9:12 pm by Miguel
Por favor, echadle un ojo a la entrada de Wikipedia al respecto de los antipatrones de diseño, hay una recopilación estupenda de muchos de ellos.
La verdad, es graciosísimo ver el montón que hemos visto implementar, o que incluso nosotros mismos hemos estado implementando estos últimos días
http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o
Saludos.
Miguel.
Permalink
01.09.08
Posted in .NET, Herramientas, Java, Patrones, Programación, Ruby On Rails, Web at 11:49 pm by Miguel
En el anterior post vimos un artículo donde se mostraba cómo trabajar con MVC + ASP.NET en Visual Studio 2005.
Para los que habéis aplicado MVC en J2EE o en Ruby on Rails os parecerá una aplicación pobre del MVC, pero bueno era lo que teníamos en su momento para ASP.NET, y los que queríamos acercarnos a ese modelo no nos quedaba más remedio que aproximarnos lo más posible a él con las herramientas con las que contábamos.
Ahora, con Visual Studio 2008 la cosa ha cambiado, y tenemos un tipo de proyecto que explota explícitamente el patrón MVC en ASP.NET.
He encontrado un artículo estupendo que habla de ello del cual os dejo el link más abajo, y que además da la puntilla dando unos toques de LINQ.
Por cierto, atención con el modelo de convenciones que utiliza el nuevo MVC para ASP.NET, para los que conozcáis Ruby on Rails os va a resultar ciertamente familiar. Es curioso como las buenas ideas se extienden como la pólvora por las diferentes herramientas de desarrollo.
Os dejo el link:
http://thinkingindotnet.wordpress.com/2007/11/18/aspnet-mvc-framework-primera-parte/
Un saludo.
Miguel.
Permalink
01.03.08
Posted in .NET, Arquitectura, Patrones, Programación, Web at 8:15 pm by Miguel
Para los defensores de que el patrón MVC es algo que viene de Java y que ASP.NET no está preparado para llevarlo a cabo, por favor, consulten el siguiente enlace en el que se muestra un ejemplo muy muy sencillo de implementación del patrón
http://msdn2.microsoft.com/en-us/library/ms998540.aspx
Para los interesados en ver un ejemplo magistral de implementación de una aplicación ASP.NET en N-CAPAS, os recomiendo consultar el siguiente enlace
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416
Un saludo a todos y feliz año.
Miguel.
Permalink
12.24.07
Posted in .NET, Patrones, Programación at 1:01 pm by Miguel
Unos post más atrás (si no recuerdo mal hablando de .NET Remoting) surgió en la conversación el patrón Façade. Es más,incluso se adjuntó un diagrama de arquitectura donde veíamos implementado el patrón dando vida a la convivencia de servicios web y servicios de remoting en la misma arquitectura.
En su día prometí dedicar un post al patrón Façade, pero como este implementa otro patrón llamado Factory, creo que mejor antes vamos a por el Factory para luego atacar Façade con un poco más de base.
El patrón Factory entra en el grupo de patrones de creación (donde también podemos encontrar Singleton del cual ya hemos hablado también en otros post). Los patrones de creación, tal como su nombre indica, se dedica a crear objetos y a encapsular dicha creación para abstraernos de la misma (lo de siempre quitar trabajo, elevar la productividad y la mantenibilidad).
Os dejo aquí un PDF interesante al respecto de los patrones de creación por si os interesa el tema a fondo, vienen bastantes ejemplos.
http://www.dei.inf.uc3m.es/docencia/p_s_ciclo/tdp/curso0203/apuntes/factory.pdf
De todas maneras, lo de siempre, yo os voy a dejar una muestra muy pequeña que os sirva de punto de partida y ya luego si os interesa a fondo os metéis a saco teniendo la base ya firme.
Antes de empezar, contaros que hay tres tipos de patrones Factory: Simple Factory, Factory Method y Abstract Factory y aquí en principio sólo vamos a hablar de Simple Factory ya que es el patrón que usa Façade, que es a lo que queremos llegar.
Aprovecho y hago un inciso, es importante en esta profesión centrarse en el problema y no irse por las ramas, si sabéis que algo soluciona vuestro problema, a por ello, no os pongáis a mirar y mirar y mirar, porque el tiempo se os va a ir y la fecha de entrega de un proyecto suele ser fija Fin del inciso.
Factoría Simple + Strategy (mira tú por donde nos aparece otro patrón)
Allí va un ejemplo, a ver si quedan las cosas claras.
Primero una interfaz Vehículo (código C#):
public interface Vehiculo
{
public void Arrancar();
public void Frenar();
public void GirarIzquierda();
public void GirarDerecha();
}
Como véis la interfaz vehículo lo que hace es definir una serie de comportamientos comunes a cualquier vehículo.
Ahora implementemos dos vehículos.
public class Coche : Vehiculo
{
public void Arrancar()
{
// Código necesario para arrancar el coche.
}
… Resto de métodos de Vehículo …
}
public class Moto : Vehiculo
{
public void Arrancar()
{
// Código necesario para arrancar la moto
// que no es igual al del coche claro
}
… Resto de métodos de Vehículo …
}
Como véis lo único que hemos hecho aquí es implementar los métodos de un vehículo para un coche y una moto. Hemos definido cómo actúan cada uno por separado. Hemos encapsulado dicho comportamiento en las clases que heredan de vehículo.
Y ahora ya “la magia”, la factoría que genera vehículos:
public class FactoriaVehiculo
{
public static Vehiculo GetVehiculo (TipoEnumeradoVehiculo vehiculo)
{
switch (TipoEnumeradoVehiculo)
{
case vehiculo.Coche:
return new Coche();
break;
case vehiculo.Moto:
return new Moto();
break;
default:
return null;
break;
}
}
}
Hemos utilizado un Tipo Enumerado auxiliar para hacer esto más legible y sobre todo más encapsulado. Otra opción era pasarle a GetVehículo un String… pero claro, estamos en lo de siempre, si le pasamos un string estamos dando por hecho que sabemos que hace por dentro la factoría, cuando no tiene por qué ser así.
Bien, por último, vamos a crear un procedimiento que utilice la factoría, para así acabar de darle forma al asunto:
public void EjemploFactoria()
{
// lista genérica, SIEMPRE QUE SEA POSIBLE
List<Vehiculo> listaVehiculos = new List<Vehiculo>;
// añadimos vehículos a la lista genérica
listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.Coche));
listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.Moto));
listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.MotoConSidecar));
listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.TodoTerreno));
// recorremos la lista de vehículos
foreach (Vehiculo unVehiculo in listaVehiculos)
{
unVehiculo.Arrancar();
}
}
¿Queda claro? La factoría ha ocultado cómo se crean las clases y las ha devuelto ya generadas. Por cierto, hemos hablado antes del patrón Strategy… ¿pero dónde aparece? Pues lo vemos en funcionamiento en la línea unVehiculo.Arrancar(). Cada vehículo arrancará como tenga definido, esa es su estrategia. Strategy es un patrón muy simple y que seguramente habréis implementado muchas veces pero sin haberlo llamado nunca así Os dejo el link de la wikipedia al respecto aquí para que le echéis un ojo.
Por cierto, menudo ejemplo de polimorfismo nos ha salido también, ¿no? Ahora que caigo, ¿podríamos definir el polimorfismo como sinónimo de patrón strategy? Tengo que investigarlo.
Más cosas también para terminar, en otros posts también se habló de crear factorías de DAO’s, ¿se ve ahora un poco mejor el tema?
¡Saludos a todos y feliz navidad!
Miguel.
Permalink
12.03.07
Posted in Patrones, Programación at 9:07 pm by Miguel
Y lo prometido es deuda, aquí viene un pequeño artículo con una idea para hacer las llamadas a vuestros DAOs transaccionales de forma totalmente transparente.
Hasta ahora por lo que habíamos visto éramos capaces conociendo y aplicando los patrones DAO+DTO de encapsular nuestras llamadas al modelo de negocio, ordenarlas cada una en su DAO correspondiente, garantizar una única instancia de cada uno de los DAO utilizando un Singleton… y algunas cosillas más.
Pero algo que nos quedaba pendiente resolver era cómo hacer que las llamadas a nuestros DAO se llevaran a cabo de forma transaccional. Es decir, que en caso de que en varias llamadas consecutivas a nuestros DAO (llamdas que alteren el contenido de una entidad de destino), podamos volver al estado anterior en caso de que ocurra un error en la aplicación.
Me explico. Por lo que conocíamos por ahora podíamos hacer lo siguiente.
try
{
// insertamos tres coches
CocheDAO.GetInstance().Insert(codigocoche1, “seat”);
CocheDAO.GetInstance().Insert(codigocoche2, “mercedes”);
CocheDAO.GetInstance().Insert(codigocoche3, “renault”);
// actualizamos el coche 2
CocheDAO.GetInstance().Update(codigocoche2, “honda”);
// borramos el coche 1
CocheDAO.GetInstance().Delete(codigocoche1);
}
catch (Exception ex)
{
TratarExcepcion(ex);
}
Y qué ocurre si al insertar el coche número 3 la aplicación falla. Pues que se habrán creado dos coches que quedarán colgados en la base de datos. ¿Cómo solucionamos esto? Creando una transacción. Pero claro, entonces aquí viene el gran problema… ¿de dónde narices saco la transacción si no tengo acceso a la conexión de base de datos? Este es el chiste del DAO, que no veo la conexión, es totalmente transparente a mi… entonces… ¿cómo voy a hacer algo transaccional?
Entonces es cuando aparece la idea feliz y nos inventamos unas transacciones propias para los DAO. Algo así como un TransactionDAO. Entonces nuestro código anterior cambia un poco y pasa a ser el siguiente:
try
{
TransactionDAO tran = BaseDAO.BeginTransaction();
// insertamos tres coches
CocheDAO.GetInstance().Insert(tran, codigocoche1, “seat”);
CocheDAO.GetInstance().Insert(tran, codigocoche2, “mercedes”);
CocheDAO.GetInstance().Insert(tran, codigocoche3, “renault”);
// actualizamos el coche 2
CocheDAO.GetInstance().Update(tran, codigocoche2, “honda”);
// borramos el coche 1
CocheDAO.GetInstance().Delete(tran, codigocoche1);
tran.Commit();
}
catch (Exception ex)
{
tran.Rollback();
TratarExcepcion(ex);
}
Parece esto una llamada a transaccional típica, ¿no? Pero hay una sustancial diferencia, es que la transacción no es una transacción de base de datos que nos pueda proveer por ejemplo .NET (SqlTransaction) si no que es una transacción propia del DAO y que nos provee para hacer las llamadas transaccionales. El cómo implemente internamente la transacción el DAO ya es problema suyo, y me explico. En el caso que el DAO esté atacando a una base de datos internamente implementará una arquitectura trabajando con SqlCommand y SqlTransaction… pero… ¿y si está llamando a Servicios Web? ¿Y si está atacando a ficheros de texto? ¡¡Pues ya lo definirá internamente!! Eso es totalmente transparente a la capa que llama a los DAO.
En el caso del ejemplo hemos implementado llamadas a métodos BeginTransaction, Rollback y Commit en nuestro BaseDAO, que es el que internamente gestiona las transacciones. ¿Cómo puede funcionar esto internamente? Pues por ejemplo manteniendo BaseDAO una lista genérica de de TransaccionDAO, la cual irá aumentando y disminuyendo a medida que los clientes pidan y confirmen transacciones.
Tal vez quede perfilar un poco más cómo maneja BaseDAO ese pool de transacciones… eso lo haremos en otro artículo. Dejo alguna pregunta abierta ¿qué ocurre si creamos transacciones y luego no hacemos rollback o commit de ellas? Deberiamos currarnos la caducidad de dichas transacciones…
Saludos.
Miguel.
Permalink
« Previous entries Next Page » Next Page »