PATRON DAO

7/17/2019 PATRON DAO

http://slidepdf.com/reader/full/patron-dao 1/9

Patrón de Diseño MVC (ModeloVista Controlador) y DAO (Data

Patrón DAO (Data Access Object)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 b!ect "T#

Transfer Object

El ori$en de este patrón sur$e por el uso de EJ%& 'os EJ% son una instancia de clase remota a

la cual se accede por mecanismos ()*.

¿Que, qué es un EJB?

En otro momento entrar+ en detalles mas t+cnicos, por ahora lo eplicar+ mu- someramente.

%asado en un patrón omain )odel, se identifican todas las entidades de ne$ocio - se

transforman a clases, de las cuales se $eneran instancias. 'as clases contienen cierta ló$ica

del ne$ocio o dominio, es decir, son como ob!etos especializados en resol/er al$0n tema

particular.

Pero... 1qu+ pasa si ha- muchos sistemas que necesitan utilizar estas clases. Es entonces

cuando entran en escena los EJ%. 'o que se le ocurrió a SUN, fue $enerar un contenedor de

instancias de las entidades de ne$ocio, una ca!ita donde siempre estu/ieran disponibles los

b!etos, lo cual tambi+n si$nifica, que deber3an estar aislados del resto de aplicaciones o por lo

menos separados del resto.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html








e esta manera, cualquiera podr3a utilizar la ló$ica de ne$ocio que esta almacenada en los

EJ% "si has utilizado Ser/lets te sonar4 similar#.

15 cu4l es el problema...

ado que los EJ% eisten dentro de la ca!ita, - que todo el mundo !ue$a con ellos, nadie puede

qued4rselos por mucho tiempo, es decir nin$0n cliente deber3a tomar un EJ% - re$resarlo

cuando termine de usarlo, porque que pasar3a con los dem4s clientes, tendr3an que esperar a

que el EJ% este libre - se encolar3an las solicitudes como la fila de las tortillas.

5 como los EJ% est4n basados en un patrón omain )odel, deben tener comportamiento -

propiedades de lo que est4n modelando, as3, supon$amos que tenemos un EJ% que modela la

entidad Usuario, un cliente hace una petición hacia este para obtener los datos de un usuario

en especifico, 1qu+ pasar3a, simple, se deber3a de car$ar el EJ% con los datos del usuario

que se esta buscando. Pero... si el b!eto esta en el contenedor, para traerme sus atributos

deber3a de hacer peticiones por cada atributo, al$o similar a lo si$uiente6



El primer problema es que, se hace muchas peticiones por la red hacia el EJ% - si el EJ% tiene

muchos atributos, bueno ser3a un cal/ario obtener cada uno de ellos - la red se estresar3a

mucho.

El se$undo problema es mas comple!o, para esto /eamos el si$uiente dia$rama.

El cliente7 lanza una solicitud para obtener los datos de un usuario, el EJ% se car$a con esta

inforación - el cliente7 comienza la tarea de sacar la información, pero si antes de que termine

lle$a un cliente2 - lanza otra solicitud para obtener datos de otro usuario, cuando el cliente7

saque el si$uiente dato 1'os datos de quien estar3a /iendo claro los de la se$unda petición,

esto es un problema de concurrencia.

5 como solucionar este problema6 89:N, 89:N, 89:N, 89::::NN, es cuando aparecen en

escena los Transfer b!ect.

'a idea es $uardar toda la información con la que deber3a de car$arse el EJ% en un ob!eto

independiente, un ob!eto que solo conten$a los atributos de la entidad Usuario, - de/ol/er este

ob!eto al cliente, as3 de!ar3a en paz al EJ% mas r4pido, la red se estresar3a menos - no habr3a

el problema de concurrencia.



:s3 solo se hace un llamado al EJ%, no se estresa la red - el EJ% queda libre para se$uir

recibiendo peticiones.

1Entonces todo este rollo fue para decir que un Transfer b!ect, es un ob!eto que solo sir/e

como un mecanismo para transportar información de un punto a otro - que no tiene

comportamiento

'a respuesta es S*, solo es un ob!eto que sir/e para transportar información al i$ual que si se

hiciera mediante una estructura ;)' o JSN.

De regreso al patrón DAO

:hora que -a sabemos que es un Transfer b!ect, podremos entender me!or lo que si$ue.

entro de las aplicaciones empresariales, el principal ob!eti/o es almacenar información de

al$una manera - en al$0n lu$ar, este lu$ar puede ser una base de datos relacional, una base

de datos orientada a ob!etos archi/os planos, o al$una otra forma que se les ocurra.

:s3 que para cada mecanismo de almacenamiento, eisten m0ltiples formas de acceder a lafuente f3sica de los datos - esto es al$o que al ne$ocio no le deber3a de importar, por tal moti/o

se debe de abstraer todo este conocimiento - en/ol/erlo en una capa.

El patrón : muestra una forma de en/ol/er ese conocimiento - e/itar que el ne$ocio se

manche las manos con esta ardua tarea, lo que si$nifica que la eplotación de los datos se

har4 mediante ob!etos :. 'a información que se obtiene de las fuentes de datos es

con/ertida o encapsulada a un ob!eto de tipo Transferb!ect, o al$una colección de estos.



:s3 el ne$ocio solo recibe por medio de ob!etos la información que necesita - no le interesa

realemente que mecanismo se utilizó para obtener la información.

En realidad el funcionamiento es mu- similar a lo que sucede con los EJ%, -a que el Transfer

b!ect si$ue siendo quien transporta la información hacia la capa que solicita la información.

Manejano !"lt#ples Data$ources% &atrón 'actor( Met)o

8uando por asares del destino nuestra aplicación debe hacer uso de muchas fuentes de datos,

se traduce en tener /arios mecanismos para obtener la informació - tendriamos un peque<o

problema 18ómo administro todos los mecanismos

*ma$inemos que tenemos que administrar = fuentes de datos, una en archi/os T;T otra en;'S"Ecel# - la 0ltima con una % (elacional, - las = tienen una estructura de datos mu-

similar para res$uardar los datos de un usuario.

Si la capa de ne$ocio no debe enterarse de como se estrae la información 1qu+ hacer

El patron >actor- )ethod nos dice como poder solucionar este problema



: la capa cliente no le interesa como leen - escriben los datos, el solo sabe que debe recibir un

T que modela un Usuario - tambien debe saber de donde quiere sacar la información. :s3 elcliente hace esta elección por medio del >actor-ao

Si esto lo completamos con un Tranfer b!ect - un patrón Sin$leton, tenemos ahora al$o mas

robusto - fleible para mane!ar multiples fuentes de datos.

A trabajar se a #c)o



Pon$amos un poco de códi$o para reforzar esto6

?amos a retomar el e!emplo de los dia$ramas, modelando una estructura de datos de Usuarios

8lase >actror-6

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 TtFactoryDao();

case MYSQL_FACTORY: return new !y"#lFactoryDao();

$efault:

throw new %lle&al'r&uentception();

*

*

*

'a clase factro- se encar$a $enerar los ob!etos >actor-ao para cada una de las fuentes de

datos, esto lo hace mediante el m+todo est4tico getFactory(int) - obli$a a quien lo

implemente a sobreescribir el m+todo getUsuarioDao().

*nterfaz Usuarioao

public interface UsuarioDao {

UsuarioT+ buscarUsuario("trin& nobre); voi$ insertarUsuario(UsuarioT+ usuario); voi$ modiicarUsuario(UsuarioT+ usuario);

*

Se define cuales son los m+todos que tendr4n todos los :@s que quieran ser un Usuarioao

8lase )-SA'>actor-ao

public class MyS!"FactoryDao eten$s FactoryDao {

,+verri$e

public UsuarioDao getUsuarioDao() { return new UsuarioMyS!"FactoryDao(); *

*

Etiende la clase >actor-ao e implementa el metodo $etUsuarioao, $enerando un ob!eto



que consuma el data source que necesita, en esta caso una base de datos )-SA'

8lase Tt>actor-ao

public class T#tFactoryDao eten$s FactoryDao{

,+verri$e public UsuarioDao getUsuarioDao() { return new UsuarioT-TFactoryDao();

*

*

curre lo mismo que la clase )-SA'>actor-ao sal/o que ahora se $enera un ob!eto de

UsuarioT;T>actor-ao"#

8lase Usuario)-SA'>actor-ao

public class UsuarioMyS!"FactoryDao ipleents UsuarioDao {

private .onnectionDao cn;

public UsuarioMyS!"FactoryDao() { cn = .onnectionDao/&et%nstance();

*

public UsuarioT+ buscarUsuario("trin& nobre) { throw new Unsupporte$+perationception(0ot supporte$ yet/0);

*

public voi$ insertarUsuario(UsuarioT+ usuario) {

throw new Unsupporte$+perationception(0ot supporte$ yet/0); *

public voi$ modiicarUsuario(UsuarioT+ usuario) { throw new Unsupporte$+perationception(0ot supporte$ yet/0);

*

*

'as operaciones que esta clase hace son diri$idas hacia una sola fuente de datos "Una %ase

de atos en )-SA'#

8lase UsuarioT;T>actor-ao

public class UsuarioTXTFactoryDao ipleents UsuarioDao {

public UsuarioT-TFactoryDao() {

*

public UsuarioT+ buscarUsuario("trin& nobre) { throw new Unsupporte$+perationception(0ot supporte$ yet/0);

*

public voi$ insertarUsuario(UsuarioT+ usuario) {

throw new Unsupporte$+perationception(0ot supporte$ yet/0); *



public voi$ o$ificarUsuario(UsuarioT+ usuario) {

throw new Unsupporte$+perationception(0ot supporte$ yet/0);

*

*

:hora las operaciones son sobre un archi/o de teto

8lase UsuarioT

public class UsuarioT+ {

private "trin& nobre;

private "trin& apelli$o;

private int e$a$;

!3to$os set y &et

*

Es la clase mediante la cual se transformar4n los datos de las diferentes fuentes de datos

8lase 8liente

public class .liente {

private FactoryDao t#tFactory =

FactoryDao/&etFactory(FactoryDao/ TXT_FACTORY);

private UsuarioDao usuarioDao = t#tFactory/&etUsuarioDao();

public UsuarioT+ buscarUsuario("trin& nobre){ return usuarioDao/buscarUsuario(nobre); *

public voi$ insertarUsuario("trin& nobre4 "trin& apelli$o4 int e$a$){

UsuarioT+ usuario = new UsuarioT+();

usuario/setobre(nobre);

usuario/set'pelli$o(apelli$o);

usuario/set$a$(e$a$);

usuarioDao/insertarUsuario(usuario); *

*

:hora la clase 8liente decide que fuente de datos usar por medio del m+todo $et>actor-"#, de

el cual se puede obtener un ob!eto que implemente la interfaz Usuarioao. El resto de las

operaciones sobre Usuarioao son mu- transparentes para la clase cliente, -a que no se

entera de como hace su proceso para etraer - $uardar información

Documents

PATRON DAO