Patrn de Diseo MVC (Modelo

Vista Controlador) y DAO (Data

Patrn DAO (Data Access Object)
Es un patrn canonizado por SUN, el cual se encuentra dentro de la definicin de los J2EE
Patterns.
Pero... para empezar a hablar sobre este patrn, primero deberemos entender que son los
Tansfer Object (TO)

Transfer Object
El origen de este patrn 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 tcnicos, por ahora lo explicar muy someramente.
Basado en un patrn Domain Model, se identifican todas las entidades de negocio y se
transforman a clases, de las cuales se generan instancias. Las clases contienen cierta lgica
del negocio o dominio, es decir, son como objetos especializados en resolver algn 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 tambin significa, que deberan estar aislados del resto de aplicaciones o por lo
menos separados del resto.

De esta manera, cualquiera podra utilizar la lgica de negocio que esta almacenada en los
EJB (si has utilizado Servlets te sonar similar).
Y cul es el problema?...
Dado que los EJB existen dentro de la cajita, y que todo el mundo juega con ellos, nadie puede
quedrselos por mucho tiempo, es decir ningn cliente debera tomar un EJB y regresarlo
cuando termine de usarlo, porque que pasara con los dems clientes, tendran que esperar a
que el EJB este libre y se encolaran las solicitudes como la fila de las tortillas.
Y como los EJB estn basados en un patrn Domain Model, deben tener comportamiento y
propiedades de lo que estn modelando, as, supongamos que tenemos un EJB que modela la
entidad Usuario, un cliente hace una peticin hacia este para obtener los datos de un usuario
en especifico, qu pasara?, simple, se debera 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
debera 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 sera un calvario obtener cada uno de ellos y la red se estresara
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
inforacin y el cliente1 comienza la tarea de sacar la informacin, 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 estara viendo? claro los de la segunda peticin,
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 informacin con la que debera 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 dejara en paz al EJB mas rpido, la red se estresara menos y no habra
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 informacin de un punto a otro y que no tiene
comportamiento?
La respuesta es SI, solo es un objeto que sirve para transportar informacin al igual que si se
hiciera mediante una estructura XML o JSON.

De regreso al patrn 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 informacin de
alguna manera y en algn 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 mltiples formas de acceder a la
fuente fsica de los datos y esto es algo que al negocio no le debera de importar, por tal motivo
se debe de abstraer todo este conocimiento y envolverlo en una capa.
El patrn 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 explotacin de los datos se
har mediante objetos DAO. La informacin que se obtiene de las fuentes de datos es
convertida o encapsulada a un objeto de tipo TransferObject, o alguna coleccin de estos.

As el negocio solo recibe por medio de objetos la informacin que necesita y no le interesa
realemente que mecanismo se utiliz para obtener la informacin.
En realidad el funcionamiento es muy similar a lo que sucede con los EJB, ya que el Transfer
Object sigue siendo quien transporta la informacin hacia la capa que solicita la informacin.
Manejando mltiples DataSources: Patrn Factory Method
Cuando por asares del destino nuestra aplicacin debe hacer uso de muchas fuentes de datos,
se traduce en tener varios mecanismos para obtener la informaci y tendriamos un pequeo
problema Cmo 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 informacin 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 informacin. As el
cliente hace esta eleccin por medio del FactoryDao

Si esto lo completamos con un Tranfer Object y un patrn Singleton, tenemos ahora algo mas
robusto y flexible para manejar multiples fuentes de datos.
A trabajar se a dicho

Pongamos un poco de cdigo 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 mtodo esttico getFactory(int) y obliga a quien lo
implemente a sobreescribir el mtodo getUsuarioDao().
Interfaz UsuarioDao
public interface UsuarioDao {
UsuarioTO buscarUsuario(String nombre);
void insertarUsuario(UsuarioTO usuario);
void modificarUsuario(UsuarioTO usuario);
}

Se define cuales son los mtodos que tendrn 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;

//Mtodos set y get

Es la clase mediante la cual se transformarn 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 mtodo 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 informacin