El Rincón del Programadorcito

Capa de Negocio (Parte 2): Domain Model

2010-11-19T12:25:00.002-06:00

Continuando con los patrones de la capa de negocio llega el turno de Domain Model

Patrón Domain Model

Al contrario que el patrón Transaction Script, la idea ahora es poder soportar lógica de negocio muy compleja por medio de Clases (si ahora solo puede ser POO).

El patrón Domain Model, nos dice que ahora habrá que modelar el negocio y bajarlo a nivel de entidades, que en algún momento se traducirán a clases.

En muchas ocasiones se confunde el Modelo de Dominio con el Modelo Entidad - Relación (Diagrama de la base de datos), cuando lo cierto es que estos dos modelos son muy diferentes, ya que el modelo de dominio no solo maneja datos, si no también procesos y algunos expertos dicen que tampoco debe permitir herencia.

Por ejemplo: Imaginemos que queremos modelar el proceso de apertura de una cuenta bancaria. Para abrir una cuenta bancaria se necesita un cliente, una operación de apertura(un deposito) y crear obviamente una nueva cuenta.

Seguramente un E-R para este tipo de procesos será mas complejo, pero para fines explicativos, creo que será suficiente.

Ahora vamos a ver como se vería un Modelo de Dominio

Ah!!, ya no son tan iguales cierto, y es que el modelo de dominio tiende a encapsular de alguna manera comportamiento, que puede afectar a mas de una tabla, como es el caso de la entidad "CuentaBancaria".

Tan solo el método crearCuenta de alguna manera invoca peticiones hacia las tablas CUENTA_BANCARIA, TIPO_CUENTA, OPERACION_BANCARIA y TIPO_OPERACION

Y porque no crear una clase llamada "OperacionBancaria", la respuesta es muy simple, no se me ocurre algún método particular para esta clase, es decir, operacionBancaria es una buena tabla para poder almacenar todas las transacciones que hacemos con la cuenta, cargos o abonos y al final podemos sacar un buen estado de cuenta de esta tabla, pero no tiene comportamiento propio, y es que el problema de tener Clases que no tengan comportamiento propio nos hace caer en un Antipatrón llamado "Anemic Domain Model"

¿Qué es el Antipatrón " Anemic Domain Model" (Modelo de Dominio Flaco)?

Como su nombre indica un Antipatrón es algo como el Némesis de un patrón, un enemigo natural, pero como todo enemigo natural siempre hay algo que comparten, algo que los hace acérrimos rivales puede ser la fuerza, velocidad o algo. En este caso en particular es que ambos son Clases.

Incurrimos en este antipatrón cuando tenemos Clases sin comportamiento y que solo tienen Atributos o viceversa. Dado que los objetos de alguna manera tratan de modelar nuestra realidad no hay objetos que no tengan una funcionalidad especifica, o que no tengan características, no podría imaginar algún objeto que no sirva para nada o que no tenga ninguna característica.

Por esta razón se les denominan anémicos, porque les hace falta comer algo para estar en forma, le hace falta tener o bien métodos o bien atributos.

¿Como se cuales son las entidades de negocio?

La verdad no es tan complicado, solo hay que responder algunas preguntas:

¿Qué es?
¿Para qué sirve?
¿Cómo funciona?
¿Qué características tiene?

Si aplicamos esto al ejemplo anterior, podemos observar los siguiente:

 

 Entidad: Cuenta Bancaria.

¿Que es? Es un concepto de banco que esta asociado a un Cliente, una Cuenta Bancaria es el eje principal para hacer operaciones y es la relación entre el Banco y el Cliente.

¿Para que sirve? Es una especie de caja fuerte, en la cual un cliente puede guardar dinero electrónico, y disponer de el mediante algún mecanismo igualmente electrónico.

¿Como funciona? Inicialmente debe ser creada con un deposito (agregar dinero a la caja), puede incrementar el saldo por medio depósitos en ventanilla o alguna transferencia electrónica a favor de la cuenta a lo cual se le denomina "abono" a la cuenta, para disponer del contenido se puede hacer mediante un pago electrónico o disposición de efectivo, a lo cual se le denomina "Cargo".



¿Que características tiene? Cada cuenta es de un tipo especifico (Nómina, Ahorro, etc.), esta ligada a un solo Cliente pero un cliente puede tener muchas, tiene una fecha de apertura siempre debe contar con una cantidad de dinero disponible y los movimientos bancarios que ha tenido.

Cuando la entidad que se desea validar responde todas las preguntas fácilmente, es muy claro que es una verdadera entidad. Ahora vamos a intentar validar el concepto Operación Bancaria.

 

 Entidad: Operación Bancaria

¿Que es? Es una transacción que involucra una cuenta y un movimiento ya sea de cargo o abono hacia la misma.

¿Para que sirve? Para marcar un movimiento de una Cuenta Bancaria.

¿Como funciona? Cuando una Cuenta Bancaria hace un movimiento de entra o salida de dinero esto genera una operación bancaria, la cual es de un tipo(Cargo o Abono).

¿Que características tiene? Fecha de la operación, Tipo de movimiento e Importe.

"Oye, pero si contestó todas las preguntas", es cierto pero analicemos las respuestas:

Es muy claro que tiene características y muy importantes por cierto, pero el funcionamiento, esta 100% ligado a un resultado de otra entidad "Cuenta Bancaria", lo que quiere decir que no tiene comportamiento propio y en todas sus respuestas siempre menciona "Cuenta Bancaria", lo que quiere decir que es una parte o consecuencia de una Cuenta Bancaria.

No digo que se tenga que hacer esto a todas las entidades de negocio, pero es una buena forma de salir de dudas, sobre todo con aquellas entidades de las que no estamos tan seguros.

Pros y contras

Ahora vamos a lo interesante

Pros:

Nos permite modelar de una forma mas adecuada como funciona un negocio.
Aplicar cambios en el negocio es muy sencillo.
No hay replicación de código.
Las refactorizaciones se resumen a una clase especifica y no a todo el sistema.
Si el negocio crece, es mas sencillo modelarlo y cambiar el código.
Las pruebas se reducen a probar el funcionamiento de cada clase y como se comporta.

Contras:

Los errores no detectados en el modelo de dominio pueden repercutir seriamente en un futuro.
El proceso de desarrollo depende de la especificación del modelo, por lo tanto tiende a ser mas lento.
Para validar el modelo, en ocasiones hacen falta varias revisiones, lo cual también toma cierto tiempo.

Conclusión

Si tienes un negocio muy complejo y/o cambiante y el tiempo no es un asunto de mucha relevancia (en el mundo del desarrollo eso es una epifanía), esta es una muy buena alternativa para solucionar el problema.

En el siguiente y ultimo articulo correspondiente a la Capa de Negocio veremos que es el Table Module y pueden revisar el patron anterior Transaction Script

Capa de Negocio (Parte 3): Table Module

2010-11-19T12:22:00.004-06:00

Patrón Table Module

Es último patrón y no por eso el menos importante.

Este patrón tiene su base en el modelo E-R de una base de datos, ya que ahora las clases contendías en la capa de negocio son una representación de las tablas de la base de datos.

Es decir que ahora habrá una Clase que se encargará de administrar todo el comportamiento y lo datos que una tabla en particular.

La diferencia principal entre el Domain Model y el Table Module es que, mientras que con el patrón Domain Model manejas un objeto por cada Cuenta Bancaria (retomando el ejemplo anterior) con Table Module, tendrás un solo objeto para manejar todas las Cuentas Bancarias y ahora si tendrás una clase llamada "OperacionBancaria".

Este Patrón hace uso de la fortaleza que tienen las bases de datos relacionales, como los índices de las tablas mediante los cuales podemos obtener información particular de una forma mas rápida.

Retomemos el ejemplo de la base de datos anterior.

Así un diagrama de clases para este patrón, luciría muy semejante, por no decir igual.

Las llaves primarias de una tabla es un índice natural de la tabla, por tanto podemos explotarlo y preguntar por una cuenta Bancaria por un "Id" especifico, lo cual nos sugeriría tener un método para dicho fin, algo semejante a lo siguiente:

cuentaBancaria.getCuentaBancariaById(long idCuentaBancaria)

El patrón puede aplicarse por medio de una instancia de clase o bien una serie de métodos estáticos, y eso es gracias a que la clase original no guarda comportamiento especifico para cada una de las cuentas bancarias por el contrario, debe mantenerse lo mas neutral posible.

Cada clase podría incluir una fábrica de sentencias SQL o delegar esto a la capa de datos por medio de un patrón Table Data Gateway (prometo que pronto habrá un articulo hablando de este patrón), lo cual simplificaría aún mas las cosas y permitiría manejar de una forma mas natural las operaciones sobre la tabla en cuestión.

Algunas veces llego a pensar que este patrón es una mezcla entre el Domain Model y el Transacction Script, si utilizamos un patrón Command, ya que ahora cada clase podría definirse como una clase de dominio y un proceso esta conformado a menudo por varias clases para conformar una transacción, si le aplicábamos un patrón Commnad, el manejo transaccional es relativamente sencillo.

Pros y Contras

Al igual que los patrones anteriores tiene algunas cosas buenas y otras que no lo son tanto.

Pros:

Dado que esta basado en la estructura de un E-R, hace que la propia tabla este estrechamente ligada a la capa de negocio lo cual hace que las operaciones con la tabla sean fácilmente programables y comprobables.
Cada Clase aísla las operaciones sobre una tabla, por tal motivo si la base de datos tiende a cambiar, es muy fácil soportar este cambio.
Cuando un cambio en la base de datos surge por la necesidad de mostrar algún dato extra en la vista, los cambios en el diseño de la aplicación son prácticamente nulos.
El desarrollo es sumamente sencillo, y el tiempo también baja considerablemente al tener perfectamente definida la estructura E-R del la base de datos.

Contras:

Al igual que Transaction Script, este patrón funciona muy bien con una lógica de negocio sencilla, si la lógica es compleja, se comenzará a genera una maraña de dependencias entre las Clases de negocio.
Dado que cada Clase tiene comunicación estricta con una tabla, si un proceso tiene que actuar sobre muchas tablas, podría verse reflejado esto en una baja de performance de la aplicación, aunque algunos tips sobre la capa de datos podrían ayudar (en el siguiente articulo veremos algunos).
Aplicar polimorfismo es algo complejo, ya que a final de cuentas se esta haciendo un mapeo de cada tabla, y las bases de datos relacionales carecen de habilidad polimórfica.

En conclusión

El patrón Table Model también facilita mucho el proceso de desarrollo y aunque puede cargar una lógica de negocio ciertamente compleja, entre mas compleja se vuelva esta, estaremos las cerca de comenzar a generar un código "espagueti", es decir, una maraña de dependencias y llamadas entre clases.

Pongamos todo sobre la mesa (Transaction Script, Domain Model y Table Module)

Los 3 patrones de diseño son buenos bajo ciertas circunstancias y no son necesariamente excluyentes, incluso hay casos de éxito donde se han combinado un par de patrones, aunque si es necesario manejar una documentación apropiada para saber donde se aplico un patrón y donde el otro, yo personalmente he aplicado 2 patrones simultáneamente y me ha funcionado.

El patrón Transaction Script lo utilizo principalmente para procesos sin gran trascendencia, como la alimentación de catálogos, o registro de información que posteriormente será procesada.

El patrón Domain Model lo utilizo para las operaciones rudas del negocio, para las reglas que tienen muchas validaciones o que pueden ser muy cambiantes y complejas.

El patrón Table Model, lo utilizo generalmente para sistemas con una complejidad que yo llamaría moderada y aplicando el patrón Command es posible tener procesos ciertamente poderosos y complejos sin perder mucho el hilo de que se hace en que parte.

Al final la elección de un patrón sobre de otro se resume mucho a la complejidad del proyecto y el tiempo que tenemos para desarrollarlo, aunque reitero que es posible hacer una combinación de un par de ellos y tener un buen resultado.

Próximamente tocaremos la capa de acceso a datos y la capa de vista, pero por el momento se termino la inspiración.

Un Saludo.

ORM (Object Relation Mapping) Parte 1

2010-11-19T11:19:00.003-06:00

¿Que es ORM?

Al surgir la programación orientada a objetos, todo pareció ser alegría hasta el momento de tener que enfrentarse con un dilema, "Bases de datos"

Cuando la POO comenzó a tener un gran empuje, las personas comenzaron a preguntarse porque no tener también una Base de Datos Orientada a Objetos (BDOO), así que algunos comenzaron a investigar al respecto, pero... cual fue el problema.

Las Bases de Datos Relacionales dominaban el mercado, había compañías muy sólidas respaldaban sus productos, el lenjuage SQL ya era un estándar que todos conocían y las BDOO apenas estaban en plena concepción, dado que lo mas importante para las compañías es su información (Datos), no iban a apostar por una nueva herramienta en pleno desarrollo y dejar a un lado las ya maduras Bases de Datos Relacionales. Así que el paradigma de las BDOO se fue rezagando hasta quedar prácticamente en el olvido actualmente.

En el mundo de caramelo de la POO, trabajar con una BDOO sería exelente por no decir magnifico, ya que la explotación de los datos sería mediante Objetos, es decir, se lanzaría una petición a la BD y esta en lugar de regresar un conjunto de datos como lo hace una BDR, regresaria un conjunto de objetos, representando una Entidad muy particular, así todo se manejaría a nivel de Objetos y no de datos.

Tristemente eso no paso así, lo cual presento un nuevo problema para la POO ya que no podía interactuar naturalmente con una base de datos relacional, al menos no a nivel de Objetos.

Así que para solventar este problema se creo el concepto de ORM ( algo así como "Objeto Relación Mapeo" en español). La idea es simple obtener un conjunto de datos de una base de datos relacional y convertirla en Objetos por algún mecanismo.

Para ello se idearon algunos patrones y en la actualidad existen varios frameworks para los distintos lenguajes OO que nos facilitan mucho la chamba.

Sin embargo, considero que primero hay que entender los patrones en los que se basaron estos frameworks, para tener una perspectiva mas amplia a la hora de elegir uno u otro y no solo hacer caso de la popularidad.

Así que sin mas preámbulo aquí vamos:

Nota: En los fragmentos de código, se hace uso de la clase ConnectionDao creada en el artículo Patrón Singleton

Active Record

Este patrón fue creado con la intención de solventar la deficiencia del Domain Model con las bases de datos relacionales y parece hacer lo que sería mas lógico, es decir, ofrece un mecanismo para que cada objeto de la capa de dominio modele únicamente y exclusivamente un registro de una tabla en particular y que el objeto tenga métodos para poder modificar dicho registro.

Así cada uno de los objetos Alumno, estaría representando un registro de la tabla ALUMNO y el Cliente trabajaría con cada uno de estos objetos de forma transparente.

Para obtener un mejor resultado podríamos utilizar métodos estáticos para poder obtener cada uno de los objetos Alumno, de esta manera los objetos son un tanto mas transparentes a la hora de obtener información de la base de datos

Veamos el siguiente diagrama de secuencia

Por medio del método estático buscarAlumno, se obtiene un objeto de tipo Alumno, con la información cargada de un alumno en particular y se podrían hacer operaciones con este alumno, como modificar o borrar. De esta misma manera al crear un nuevo objeto alumno estaríamos tratando por debajo con un solo registro

Un Ejemplo

Vamos a pone un pequeño ejemplo de como se vería el código hecho en java para este patrón.

TABLA Alumno

CREATE TABLE ALUMNO (

    ID INT ID PRIMARY KEY,

    NOMBRE VARCHAR(50),

    EDAD INT

  );

Ahora a crear el clase que modelará dicha tabla

Alumno.java

  public class Alumno {



    private int id;

    private String nombre;

    private int edad;



    //set's y get's

    ...

 }

Agregamos los métodos estáticos por los cuales obtendremos los datos

  public class Alumno {

    // Propiedades

    ...



    private final static String FIND_BY_ID="select * from alumno where id=?";

    public static Alumno buscarPorId(int id) throws SQLException{

        ConnectionDao cn = ConnectionDao.getInstance();

        PreparedStatement prepared = cn.getPreparedStatement(FIND_BY_ID);

        prepared.setInt(1, id);

        return loadData(prepared.executeQuery());

    }



    private static Alumno loadData(ResultSet rs) throws SQLException{

        Alumno alumno = new Alumno();

        alumno.id = rs.getInt(1);

        alumno.nombre = rs.getString(2);

        alumno.edad = rs.getInt(3);

        return alumno;

    }

}

Al final solo faltaría agregar los métodos para poder modificar la información del registro que estamos modelando

public class Alumno {

  // Propiedades

  ...



  // Métodos estáticos

  ...



  private final static String UPDATE = "update alumno set nombre = ?, " +

                                       "edad = ? where id = ?";

  public void actualizar() throws SQLException{

    ConnectionDao cn = ConnectionDao.getInstance();

    PreparedStatement prepared = cn.getPreparedStatement(UPDATE);

    prepared.setString(1, nombre);

    prepared.setInt(2, edad);

    prepared.setInt(3, id);

    prepared.executeUpdate();

  }



  private final static String INSERT = "insert into alumno values(?,?,?)";

  public void insertar() throws SQLException{

    ConnectionDao cn = ConnectionDao.getInstance();

    PreparedStatement prepared = cn.getPreparedStatement(INSERT);

    prepared.setInt(1, id);

    prepared.setString(2, nombre);

    prepared.setInt(3, edad);

    prepared.execute();

  }

}

De tal forma que ahora la clase puede modificar, insertar o borrar exactamente 1 registro de la tabla Alumno

Cuando alguna clase haga uso de este se vería así



public class Cliente {



    public void modicarAlumno(int id,String nombre,int grupo){

        try {

            Alumno alumno = Alumno.buscarPorId(id);

            alumno.setNombre(nombre);

            alumno.setEdad(id);

            alumno.actualizar();

        } catch (Exception ex) {

            ...

        }

    }



    public void nuevoAlumno(int id, String nombre, int grupo){

        try {

            Alumno alumno = new Alumno();

            alumno.setId(id);

            alumno.setNombre(nombre);

            alumno.setEdad(id);

            alumno.insertar();

        } catch (SQLException ex) {

            ...

        }

    }

}

Las operaciones que hacen los objetos alumno son muy transparentes

Pros y Contras

- Lo bueno

Es un patón bastante simple de utilizar
Resuelve de una manera muy simple la deficiencia de BDOO
Es una forma muy elegante de encapsular el manejo de las BD
Si el modelo de domino es muy similar a la estructura de la BD, el funcionamiento es muy transparente
Si la estructura de una tabla cambia, el impacto solo es en la clase que modela dicha tabla

- Lo malo

Si las operaciones con la BD son complejas, tenderá a ser mas difícil de dar mantenimiento
El patrón no impide generar 2 objetos del mismo registro, lo cual quiere decir que si se ejecutan una modificación en ambos, el segundo sobre escribirá al primero, generando un problema de concurrencia

- La conclusión

Es realmente simple integrar el patrón cuando la base de datos es prácticamente idéntica al diagrama de clases, pero si las diferencias entre ambos son grandes, es muy posible que te meta en mas problemas que de los que te saque, también se debe tomar en cuenta la concurrencia sobre los registros por generar dos objetos del mismo registro.

Hasta aquí llega la primera parte de los ORM.

Cualquier duda o comentario, no duden en hacermelo saber, ya que solo así aprenderemos los unos de los otros

Un Saludo

Patrón DAO (Data Access Object)

2010-11-05T13:54:00.002-06:00

Es un patrón canonizado por SUN, el cual se encuentra dentro de la definición de los J2EE Patterns.

Pero... para empezar a hablar sobre este patrón, primero deberemos entender que son los Tansfer Object (TO)

Transfer Object

El origen de este patrón surge por el uso de EJB; Los EJB son una instancia de clase remota a la cual se accede por mecanismos RMI.

¿Que, qué es un EJB?

En otro momento entraré en detalles mas técnicos, por ahora lo explicaré muy someramente.

Basado en un patrón Domain Model, se identifican todas las entidades de negocio y se transforman a clases, de las cuales se generan instancias. Las clases contienen cierta lógica del negocio o dominio, es decir, son como objetos especializados en resolver algún tema particular.

Pero... ¿qué pasa si hay muchos sistemas que necesitan utilizar estas clases?. Es entonces cuando entran en escena los EJB. Lo que se le ocurrió a SUN, fue generar un contenedor de instancias de las entidades de negocio, una cajita donde siempre estuvieran disponibles los Objetos, lo cual también significa, que deberían estar aislados del resto de aplicaciones o por lo menos separados del resto.

De esta manera, cualquiera podría utilizar la lógica de negocio que esta almacenada en los EJB (si has utilizado Servlets te sonará similar).

¿Y cuál es el problema?...
Dado que los EJB existen dentro de la cajita, y que todo el mundo juega con ellos, nadie puede quedárselos por mucho tiempo, es decir ningún cliente debería tomar un EJB y regresarlo cuando termine de usarlo, porque que pasaría con los demás clientes, tendrían que esperar a que el EJB este libre y se encolarían las solicitudes como la fila de las tortillas.

Y como los EJB están basados en un patrón Domain Model, deben tener comportamiento y propiedades de lo que están modelando, así, supongamos que tenemos un EJB que modela la entidad Usuario, un cliente hace una petición hacia este para obtener los datos de un usuario en especifico, ¿qué pasaría?, simple, se debería de cargar el EJB con los datos del usuario que se esta buscando. Pero... si el Objeto esta en el contenedor, para traerme sus atributos debería de hacer peticiones por cada atributo, algo similar a lo siguiente:

El primer problema es que, se hace muchas peticiones por la red hacia el EJB y si el EJB tiene muchos atributos, bueno sería un calvario obtener cada uno de ellos y la red se estresaría mucho.

El segundo problema es mas complejo, para esto veamos el siguiente diagrama.

El cliente1 lanza una solicitud para obtener los datos de un usuario, el EJB se carga con esta inforación y el cliente1 comienza la tarea de sacar la información, pero si antes de que termine llega un cliente2 y lanza otra solicitud para obtener datos de otro usuario, cuando el cliente1 saque el siguiente dato ¿Los datos de quien estaría viendo? claro los de la segunda petición, esto es un problema de concurrencia.

Y como solucionar este problema: CHAN, CHAN, CHAN, CHAAAANN, es cuando aparecen en escena los Transfer Object.

La idea es guardar toda la información con la que debería de cargarse el EJB en un objeto independiente, un objeto que solo contenga los atributos de la entidad Usuario, y devolver este objeto al cliente, así dejaría en paz al EJB mas rápido, la red se estresaría menos y no habría el problema de concurrencia.

Así solo se hace un llamado al EJB, no se estresa la red y el EJB queda libre para seguir recibiendo peticiones.

¿Entonces todo este rollo fue para decir que un Transfer Object, es un objeto que solo sirve como un mecanismo para transportar información de un punto a otro y que no tiene comportamiento?

La respuesta es SI, solo es un objeto que sirve para transportar información al igual que si se hiciera mediante una estructura XML o JSON.

De regreso al patrón DAO

Ahora que ya sabemos que es un Transfer Object, podremos entender mejor lo que sigue.

Dentro de las aplicaciones empresariales, el principal objetivo es almacenar información de alguna manera y en algún lugar, este lugar puede ser una base de datos relacional, una base de datos orientada a objetos archivos planos, o alguna otra forma que se les ocurra.

Así que para cada mecanismo de almacenamiento, existen múltiples formas de acceder a la fuente física de los datos y esto es algo que al negocio no le debería de importar, por tal motivo se debe de abstraer todo este conocimiento y envolverlo en una capa.

El patrón DAO muestra una forma de envolver ese conocimiento y evitar que el negocio se manche las manos con esta ardua tarea, lo que significa que la explotación de los datos se hará mediante objetos DAO. La información que se obtiene de las fuentes de datos es convertida o encapsulada a un objeto de tipo TransferObject, o alguna colección de estos.

Así el negocio solo recibe por medio de objetos la información que necesita y no le interesa realemente que mecanismo se utilizó para obtener la información.

En realidad el funcionamiento es muy similar a lo que sucede con los EJB, ya que el Transfer Object sigue siendo quien transporta la información hacia la capa que solicita la información.

Manejando múltiples DataSources: Patrón Factory Method

Cuando por asares del destino nuestra aplicación debe hacer uso de muchas fuentes de datos, se traduce en tener varios mecanismos para obtener la informació y tendriamos un pequeño problema ¿Cómo administro todos los mecanismos?

Imaginemos que tenemos que administrar 3 fuentes de datos, una en archivos TXT otra en XLS(Excel) y la última con una BD Relacional, y las 3 tienen una estructura de datos muy similar para resguardar los datos de un usuario.

Si la capa de negocio no debe enterarse de como se estrae la información ¿qué hacer?

El patron Factory Method nos dice como poder solucionar este problema

A la capa cliente no le interesa como leen y escriben los datos, el solo sabe que debe recibir un TO que modela un Usuario y tambien debe saber de donde quiere sacar la información. Así el cliente hace esta elección por medio del FactoryDao

Si esto lo completamos con un Tranfer Object y un patrón Singleton, tenemos ahora algo mas robusto y flexible para manejar multiples fuentes de datos.

A trabajar se a dicho

Pongamos un poco de código para reforzar esto:

Vamos a retomar el ejemplo de los diagramas, modelando una estructura de datos de Usuarios

Clase Factrory:

public abstract class FactoryDao {



    public static final int TXT_FACTORY = 1;

    public static final int MYSQL_FACTORY = 2;



    public abstract UsuarioDao getUsuarioDao();



    public static FactoryDao getFactory(int claveFactory){

        switch(claveFactory){

            case TXT_FACTORY:

                return new TxtFactoryDao();

            case MYSQL_FACTORY:

                return new MySqlFactoryDao();

            default:

                throw new IllegalArgumentException();

        }

    }

}

La clase factroy se encarga generar los objetos FactoryDao para cada una de las fuentes de datos, esto lo hace mediante el método estático getFactory(int) y obliga a quien lo implemente a sobreescribir el método getUsuarioDao().

Interfaz UsuarioDao

public interface UsuarioDao {



    UsuarioTO buscarUsuario(String nombre);

    void insertarUsuario(UsuarioTO usuario);

    void modificarUsuario(UsuarioTO usuario);



}

Se define cuales son los métodos que tendrán todos los DAO's que quieran ser un UsuarioDao

Clase MySQLFactoryDao

public class MySqlFactoryDao extends FactoryDao {



    @Override

    public UsuarioDao getUsuarioDao() {

        return new UsuarioMySqlFactoryDao();

    }



}

Extiende la clase FactoryDao e implementa el metodo getUsuarioDao, generando un objeto que consuma el data source que necesita, en esta caso una base de datos MySQL

Clase TxtFactoryDao

public class TxtFactoryDao extends FactoryDao{



    @Override

    public UsuarioDao getUsuarioDao() {

        return new UsuarioTXTFactoryDao();

    }

}

Ocurre lo mismo que la clase MySQLFactoryDao salvo que ahora se genera un objeto de UsuarioTXTFactoryDao()

Clase UsuarioMySQLFactoryDao

public class UsuarioMySqlFactoryDao implements UsuarioDao {

    

    private ConnectionDao cn;



    public UsuarioMySqlFactoryDao() {

        cn = ConnectionDao.getInstance();

    }



    public UsuarioTO buscarUsuario(String nombre) {

        throw new UnsupportedOperationException("Not supported yet.");

    }



    public void insertarUsuario(UsuarioTO usuario) {

        throw new UnsupportedOperationException("Not supported yet.");

    }



    public void modificarUsuario(UsuarioTO usuario) {

        throw new UnsupportedOperationException("Not supported yet.");

    }

}

Las operaciones que esta clase hace son dirigidas hacia una sola fuente de datos (Una Base de Datos en MySQL)

Clase UsuarioTXTFactoryDao

public class UsuarioTXTFactoryDao implements UsuarioDao {



    public UsuarioTXTFactoryDao() {

        

    }



    public UsuarioTO buscarUsuario(String nombre) {

        throw new UnsupportedOperationException("Not supported yet.");

    }



    public void insertarUsuario(UsuarioTO usuario) {

        throw new UnsupportedOperationException("Not supported yet.");

    }



    public void modificarUsuario(UsuarioTO usuario) {

        throw new UnsupportedOperationException("Not supported yet.");

    }

}

Ahora las operaciones son sobre un archivo de texto

Clase UsuarioTO

public class UsuarioTO {



    private String nombre;

    private String apellido;

    private int edad;

//Métodos set y get

Es la clase mediante la cual se transformarán los datos de las diferentes fuentes de datos

Clase Cliente

public class Cliente {



    private FactoryDao txtFactory =

FactoryDao.getFactory(FactoryDao.TXT_FACTORY);



    private UsuarioDao usuarioDao = txtFactory.getUsuarioDao();



    public UsuarioTO buscarUsuario(String nombre){

        return usuarioDao.buscarUsuario(nombre);

    }



    public void insertarUsuario(String nombre, String apellido, int edad){

        UsuarioTO usuario = new UsuarioTO();

        usuario.setNombre(nombre);

        usuario.setApellido(apellido);

        usuario.setEdad(edad);

        usuarioDao.insertarUsuario(usuario);

    }



}

Ahora la clase Cliente decide que fuente de datos usar por medio del método getFactory(), de el cual se puede obtener un objeto que implemente la interfaz UsuarioDao. El resto de las operaciones sobre UsuarioDao son muy transparentes para la clase cliente, ya que no se entera de como hace su proceso para extraer y guardar información

Así concluye este articulo sobre el Patrón DAO y como extender las fuentes de datos con el patrón Factory Method

Los invito a dejar sus comentarios, dudas y por su puesto sugerencias, estamos en este proceso de mejorar así que cualquier aportación siempre es bien recibida

Un Saludo

Patrón Singleton

2010-10-27T19:52:00.002-05:00

Cuando escribí el artículo Desarrollo en capas, un amigo me comento que de alguna manera debería de explicar que es el patrón Singleton.

Bien su suplica se ha hecho realidad y para ejemplificar utilizaré Java

En realidad este patrón es muy simple. La idea básica de este patrón es que solo pueda existir una instancia de una clase en la aplicación.

El primer paso para conseguir este patrón es bloquear la forma de generar instancias de la clase, esto se hace simplemente privatizando el constructor de la clase

public class Singleton{



          private Singleton(){}

}

El punto principal de este patrón esta en los miembros de clase o miembros estáticos, ya que estos se crean mediante el ClassLoader, algo similar a las variables globales en la programación estructurada, lo cual quiere decir que su consentido es persistente por todo el ciclo de vida de la aplicación.

Así que utilizando la potencia de los miembros estáticos crearemos una instancia estática de la clase para que viva durante toda la vida de la aplicación.



public class Singleton { 



     private static Singleton singleton = new Singleton();

 

     private Singleton(){} 



}

Ahora solo falta tener alguna forma de acceder a este objeto, y esto es mediante un método estático



public class Singleton { 



    private static Singleton singleton

= new Singleton();



    private Singleton(){} 



    public static Singleton getInstance(){ 

       return Singleton.

singleton

; 

    } 

}

Cuando utilizar el patrón Singleton

La forma mas utilizada para aplicar este patrón, es para la capa de acceso a datos. Generalmente por cada operación que necesitemos hacer con la base de datos, creamos una nueva conexión, nos autentificamos y en seguida mandamos las sentencias SQL que necesitemos ejecutar.

Si aplicamos un patrón Singleton a la conexión a la base de datos y mantenemos la conexión abierta, nos evitaremos abrir y cerrar la conexión por cada petición

A continuación pongo un pequeño ejemplo de la aplicación de este patrón

Clase ConnectionDao



public class ConnectionDao {

private static

ConnectionDao connectionDao;

private

Connection connection;

private

ConnectionDao() throws ExceptionInInitializerError{ 

        try { 

           String classDriver = "...";

String url = "...";

Class.forName(classDriver).newInstance();

connection = DriverManager.getConnection(url);

} catch (Exception ex) {

throw new ExceptionInInitializerError(ex);

} 

     } 



    public ResultSet executeQuery(String query) throws SQLException{ 

       Statement statement = connection.createStatement(); 

        return statement.executeQuery(query); 

     } 



     public boolean executeNonQuery(String query) throws SQLException{ 

        Statement statement = connection.createStatement(); 

        return statement.execute(query); 

     }

    public PreparedStatement getPreparedStatement(String query)

throws SQLException{

        return connection.prepareStatement(query);

    }



    public static ConnectionDao getInstance(){ 

        if(ConnectionDao.connectionDao == null) 

           ConnectionDao.connectionDao = new ConnectionDao(); 

       return ConnectionDao.connectionDao; 

    }

}

El constructor se encarga de establecer la conexión a la base de datos, pero esta no se cierra para dejar el canal de comunicación siempre abierto.

El método estático getInstance() es el encargado de crear la instancia de la clase ConnectionDao si esta no existe y de regresar una referencia a dicha instancia

Clase UsuarioDao



public class UsuarioDao { 



    public void insertar(String... datos){

 try {

String sql = "insert ...";

ConnectionDao.getInstance().executeNonQuery(sql);

} catch (SQLException ex) {

...

public void

buscar(String... datos){

try {

String sql = "select ...";

ConnectionDao connection = ConnectionDao.getInstance();

connection.executeQuery(sql);

} catch (SQLException ex) {
...

}

public void actualizar

(String... datos){

try {

String sql = "update ...";

ConnectionDao connection = ConnectionDao.getInstance();

            PreparedStatement prepared =
                connection.getPreparedStatement(sql);
            prepared.setString(1,datos)

            prepared.executeUpdate();

        } catch (SQLException ex) {
           ...

}

}

Así para obtener la referencia al objeto ConectionDao llamamos al método ConnectionDao.getInstance(); que nos dará acceso a los metodos " executeQuery", " executeNonQuery " y "getPreparedStatement"

De esta manera concluye este pequeño tutorial sobre el patrón Singleton, si tienen alguna duda o un comentario, no duden en dejarlo e intentaré atenderlo lo mas pronto posible

Un Saludo

Capa de Negocio (Parte 1): Transaction Script

2010-10-12T18:53:00.024-05:00

Edición: Por sugerencia de varios amigos, he decidido separar este articulo por tema, al final se encuentran las ligas hacia los otros patrones

Recuerdo perfectamente que entre las capas que más trabajo me costo entender como funcionaban y como utilizar fue la capa de negocio y es que termina siendo la ultima que descubres y la última que entiendes como usar y programar, por ello decidí dar un pequeño salto en el orden de las capas para adentrarnos en este pequeño mundito. No quiero decir que no habrá articulo sobre la capa de vista, ¡por su puesto que lo habrá!, solo quise explicar de una vez por todas, lo que mas trabajo me costo entender.

La capa de negocio puede ser manejada de varias formas y en este contexto encontramos principalmente 3 contrincantes, el patrón Transaction Script, el patrón Domain Model y el patrón Table Module.

La conclusión a la cual quiero llegar al final, no es decir cual es mejor o peor, ya que los 3 tienen sus pros y contras; la idea es dar un panorama y porque no, un par de consejos del ¿como? y el ¿cuando? utilizar uno u otro y que al final te sea mas simple tomar una decisión de que patrón(es) te conviene(n) usar mas.

Ahora, vamos a echarle un ojo a los participantes para tener un lugar en la capa de negocio.

Patrón Transaction Script

La idea básica de este patrón se basa en las rutinas.

Hace algún tiempo cuando los sistemas no eran tan complejos, si queríamos que un sistema realizará una u otra operación, se programaba una rutina. Una rutina es un conjunto de pasos secuenciales, donde las tomas de decisión son muy raras, así se tenía un proceso muy concreto para realizar algo.

El patrón TS es básicamente eso, una rutina; por ejemplo, pensemos que tenemos un sistema de ventas, donde por cada venta realizada, revisamos si necesitamos poner una orden para reabastecer nuestro inventario (si ya sé, es el ejemplo del post anterior, pero funcionará!)

Veamos el siguiente diagrama:

El diagrama nos habla de una vista "PantallaVenta", una clase de negocio "PuntoDeVenta" y 3 clases de Datos "Inventario", "Pedidos" y "Ventas".

El foco de nuestra atención debe centrarse en la clase "PuntoDeVenta", esta es un ejemplo del patrón Transaction Script, ya que basándose en el concepto inicial, la clase "PuntoDeVenta" es la que rige toda la operación de venta.

Esto quiere decir, que si en algún momento cambia alguna regla de negocio con respecto a las ventas o si tenemos una incidencia con este modulo, sabremos donde apuntar con el dedo ¡aparte de al desarrollador claro!.

Este patrón puede ser utilizado de forma más elegante, si lo ayudamos con el patrón Command

El patrón Command (tu me llamas, yo los llamo)

El patrón Command, funciona básicamente como una interfaz (programáticamente hablando), que muestra cierto comportamiento a la capa de vista, y de alguna manera, encapsula toda la funcionalidad de la capa de negocio.

¿Qué dice que dijo?

La funcionalidad dentro de la clase "PuntoDeVenta" no esta en un solo método (por favor díganme que no), sino esta en varios métodos. A ojo de buen programador yo sacaría unos 5 métodos:

ValidarUnidades
RegistrarVenta
SolicitarPedido
ActualizarInventario
CalcularCominsion

Cada uno de ellos tiene cierta funcionalidad, el patrón Command nos dice que todo esto se puede agrupar, de tal forma que se llame a todos de un solo jalón.

Expresado esto en un diagrama de clases, se vería como esto:

Es decir, la capa de presentación solo puede acceder a la lógica de negocio por medio de una interfaz, y una implementación, la implementación llama de forma ordenada los métodos definidos en la clase PuntoDeVenta, es una forma muy elegante de aislar la capa de presentación y la capa de negocio.

Pros y contras

Sin duda es una forma muy fácil y rápida de programar, cuado tenemos una lógica de negocio no muy compleja, pero... que pasa cuando la complejidad aumenta. Sin duda llegará algún otro proceso de negocio que necesite registrar algún pedido, o calcular la comisión, pero dado que es parte de otro modulo tenderemos a replicar código. Esto se puede evitar si aislamos estos métodos por medio de herencia (Nada nos restringe a usarla), aún así para que nos demos cuenta de que métodos deben estar aislados, seguramente haremos una labor de refactorización, y si el negocio es muy cambiante, bueno, tenemos un verdadero problema entre manos.

Recopilando estos datos, podemos obtener las siguientes concluciones sobre este patrón.

Pros:

Fácil de desarrollar.
Si el negocio no cambia fácilmente, es fácil de mantener.
Al unirlo con el patrón Command, el manejo transaccional es muy sencillo.
Cada uno de los procesos es fácil de probar.

Contras:

Si el negocio cambia constantemente, significa una gran cantidad de cambios en las clases.
Tiene una alta tendencia a replicar código.
Cuando se hacen las refactorizaciones, se pierde más tiempo que con otro modelo.
El impacto en los cambios, sucede como un efecto de "Domino" por lo tanto, cuando se realiza un cambio en un módulo, los módulos alrededor necesitan ser probados, aún cuando estos no tienen dependencia directa.

En conclusión

Si el tiempo de desarrollo es muy limitado y el negocio no esta tan complejo y susceptible a cambios, es una muy buena opción implementar este patrón.

Ahora continuaremos con los siguientes 2 concursantes

Domain Model y Table Module

Desarrollando en Capas

2010-10-09T03:11:00.001-05:00

Hace algún tiempo llegue a trabajar a una empresa donde tenían ya algunos sistemas implementados, la empresa tenía la necesidad de añadir funcionalidad a dichos sistemas, comencé a revisarlos y me di cuenta de algo, no existía la capa de negocio (Domain o Business como la quieran llamar), me pregunte muchas veces el porque sin llegar a una respuesta, tenían 2 capas híbridas(porque no eran ni uno ni lo otro), una para la vista y una para acceso a datos, pero, las reglas del negocio estaban mezcladas entre la vista y el acceso a datos, lo cual significa que una nueva regla de negocio o una modificación involucraba mover por todos lados sin tener la certeza que funcionara, así que pensé en escribir algo sobre el como, el porque, el cuando y el donde, yo usaría las 3 capas convencionales (Presentación, Negocio y Acceso a datos).

Definitivamente una de las formas mas frecuentes que encontramos a la hora de desarrollar alguna aplicación, sistema o lo que sea que involucre código es la programación en capas (bueno hay sus excepciones).

La teoría básica de la programación en capas, es tener la posibilidad de separar partes que conforman un sistema. Pensemos en un pastel (el 3 leches es mi favorito) que esta hecho de varias capas de varios sabores y que aparte esta cubierto de merengue o cualquier otro menjurje que se les ocurra. La primera capa es ocultada por la segunda, la segunda por la tercera y así hasta tener un pastel de n capas, finalmente tendremos la cubierta que es la presentación al consumidor, aún cuando la presentación es la que atrae al comprador, si las demás capas tienen mal sabor seguramente el cliente no regresará por otro pastel.

La idea de las capas es también que podamos poner sobre esta una o varias mas con la idea de poder crear cosas diferentes sobre la misma base, imaginen un pastel como el siguiente (repito imaginen):

Si cortamos 3 rebanadas, una con fresa, otra con uva y otra con naranja, las tres sabrán a chocolate, pero la combinación con el sabor de la capa superior los hará diferentes (no necesariamente sabrá bien).

Lo mismo ocurre en los sistemas, sobre de una capa es posible montar otras, que tengan funcionalidades diferentes, pero en su interior comparten algo (similar a la herencia).

Así que una programación en capas proporciona muchos beneficios.

- Desacoplar el sistema, tener ahora varias cabezas que atacan un problema.

- Independizar el funcionamiento entre las capas.

- Aislar la repercusión de un cambio en una capa a las demás.

- Definir estándares para cada capa, de manera que cada una pueda tener sus propias reglas en su juego.

- Que sobre una capa puedan montarse muchas otras aún cuando estas tengan diferentes objetivos.

Sin embargo no todo es miel sobre hojuelas, también tiene algunas desventajas.

- El caso mas típico es que unaUI necesite mostrar algún dato y que la capa de datos no lo tenga disponible, eso significa que se deberán modificar todas las capas desde el acceso a datos hasta al interfaz de usuario.

- Entre mas capas se tengan mas lento se volverá el desempeño, generalmente cada capa tiende a hacer una "traducción" de lo que recibe para poder usarlo a su conveniencia, lo cual quiere decir que si existen 5 capas habrá 5 transformaciones, "malo", el desempeño se vuelve lento.

Entendiendo el asunto de las capas

En mis primeros ejercicios de programación en la escuela tenia que modificar archivos, y cosas así realmente era muy simple, no tenía la necesidad de separar mi código.

Mientras pasaba el tiempo comenzó a aumentar la complejidad de tal manera que ahora usábamos las Amadas y Odiadas Bases de Datos. Al principio siguiendo el mismo patrón era copiar cierta información de un archivo y pasarlo a la base de datos y viceversa. El problema llego cuando apareció un maestro que nos enseño a crear UIs, y después teníamos que crear un ABCC (Altas, Bajas, Cambios y Consultas), como todo buen estudiante, seguí el mismo patrón, una sola capa con todo el código, sin embargo después de crear un solo ABCC ahora tenia que crear varios, y tuve la necesidad reutilizar código especialmente la parte para establecer la conexión a la base de datos.

Fue así como tuve la necesidad de tener 2 capas (la verdad no las llamaba así), la capa para manejar la Interfaz del Usuario y la capa para acceder a los datos.

Hasta ahí todo era felicidad, sin embargo llego el momento de desarrollar sistemas mas complejos basados en especificaciones mas realistas lo que se llamaría como "Lógica de Negocio" o "Modelo de Dominio" o "Lógica de Dominio", se llame como se llame esta parte hace referencia a reglas especificas de como funciona alguna situación en particular, por ejemplo:

Cuando un estudiante va a reinscribirse, primero hay que ver si tiene derecho, revisando si aprobó el 50% de sus materias del curso pasado, y si tiene derecho a beca por haber obtenido un promedio "X" y además si hay cupo en las materias que selecciono.

Ahora no se trata solo de agregar un registro a la base de datos, se trata de que antes de eso hay que validar varias cosas .

Para ser franco cuando esto paso, mi primer instinto fue poner todas esas reglas como parte de la presentación y todo sencillo, pero en algún momento llego el caso que para que un alumno solicitará un certificado de estudios, debería de validar que no debiera mas del 50% de sus materias del semestre pasado, AAHHH yo ya tenia el código para hacer esto, así que "Copy/Paste", en una nueva interfaz, luego si un alumno solicitaba su numero de cuenta para pagar la inscripción se debería de revisar si tenia beca o no, SIII también tenia ese código hecho y nuevamente "Copy/Paste". En algún momento en la vida me di cuenta que tenia código repetido por todos lados, lo mismo que paso con las conexiones a la base de datos, así que pensé en aislar esa parte de código y tenerla como una "librería de funciones", lo que estaba haciendo realmente era tener una nueva capa, la capa de "Dominio", "Negocio" o "Lógica de negocio", como sea que la llamen, de tal manera que accidentalmente descubrí que una aplicación podía ser dividida en capas (aún cuando yo no las llamara así).

Después de un tiempo leyendo el libro de Patterns of Enterprice Application Architecture de Martin Fowler descubrí que lo que había hecho no estaba del todo descabellado y que era algo muy cotidiano en el mundo del desarrollo de sistemas, lo a lo cual di gracias por no estar tan loco.

Básicamente Fowler dice que esta es la forma principal de dividir un sistema en 3 capas básicas.

Capa	Uso
Presentación:	Dedicada a mostrar la información al usuario y recibir las entradas del mismo
Dominio o Negocio:	Todo lo concerniente a las reglas del negocio como validaciones y tomas de decisión
Acceso a datos o fuente de datos	El mecanismo por el cual se accede a la fuente a donde esta la información (No necesariamente debe ser una base de datos, puede ser un txt un excel u otra cosa)

Sin embargo no es una regla tallada en la piedra que tengamos estas capas o dicho mejor solo estas capas, es muy común que algunas de estas sean separadas en mas, dependiendo de los requerimientos y también el tipo de sistema que vayamos a desarrollar o las herramientas que vayamos a utilizar.

Fowler dice en su libro que hay ocasiones muy particulares cuando si es posible juntar la capa de presentación y la de dominio, específicamente cuando la complejidad de el dominio es muy baja o prácticamente nula, yo digo que no, que siempre hay que sepáralas, por una simple razón, el negocio tiene a cambiar y hacerse mas complejo, si todo esta en la presentación tendremos un problema a la larga.

Cada cosa en su lugar

También se preguntarán “Oye y que va en que parte”, bien pues resulta que todo lo que tenga que ver con acceso a datos deberíamos de ponerlo en la capa de datos, muchos la llamamos como DAO (Data Access Object), aquí deberíamos controlar desde abrir las conexiones, explotar la información o agregarla hasta cerrar las conexiones, salvo que implementes un patrón Singleton.

La parte difícil comienza cuado tienes que decidir que va en la capa de presentación y que va en la capa de negocio.

Lo que yo digo es que todas aquellas acciones que tienen que ver exclusivamente con la vista pues van en la vista, y aquellas que tienen algún matiz de ser parte de la operación de de cómo funciona algo en la empresa son parte del negocio.

Por ejemplo en la vista yo pondría validaciones sobre longitudes de campos, sobre si debe ir un campo alfanumérico y cosas por el estilo, porque estas no son parte del negocio, si se ingresa en un campo de texto un entero o una letra, no es algo que al negocio le importe.

Imaginemos que en una tienda debe aparecer una alerta en la interfaz cada vez que haga falta algún producto, si involucramos la palabra interfaz podría parecer que es parte la interfaz, cuando en realidad la interfaz esta llamado un procedimiento de negocio y tomando una decisión sobre el resultado, veamos esto en el siguiente diagrama de secuencia.

En este pequeño diagrama podemos apreciar principalmente 3 cosas.

1.- Aún cuando la vista inicia el proceso, esta no tiene ninguna participación en el procedo de toma de decisiones, solo reacciona de acuerdo a la información que obtenga de la capa de negocio, lo cual quiere decir que el proceso de saber si existe o no inventario no le pertenece.

2.- La capa de negocio toma una decisión dependiendo del nivel del inventario, si este es menor a 5 coloca un pedido esto es una “Regla de negocio” y de esto no se entera ni la capa de vista ni la capa de datos, si en algún momento la tienda crece y tenemos la necesidad de tener mejor surtidos nuestros almacenes, incrementaremos la condición y eso no afecta absolutamente a nadie.

3.- Ni a la capa de la presentación ni a la capa de negocio le interesa de donde sale la información, esto es una preocupación única y excesiva de la capa de Acceso a Datos, así si en algún momento deciden utilizar una base de datos, solo se deberá modificar la capa de acceso a datos y tampoco afecta absolutamente a nadie.

Hasa aquí llega la parte básica del desarrollo en Capas, mas adelante veremos como algunas de estas capas pueden transformarse en otras y daremos paso a nuevos patrones de diseño.