Data Access Object

7/17/2019 Data Access Object

http://slidepdf.com/reader/full/data-access-object-568fef2274319 1/6

DATA ACCESS OBJECT (DAO)DefiniciónDAO Es un patrón de diseño utilizado para crear una capa de persistenciaFuncionamiento

DAO encapsula el acceso a la base de datos. Por lo que cuando la capa lógicade negocio necesite interactuar con la base de datos, va a hacerlo a través dela API que le o rece DAO.

!eneral"ente esta API consiste en "étodos #$%D &#reate, $ead, %pdate, 'Delete(. Entonces por e)e"plo cuando la capa de lógica de negocio necesiteguardar un dato en la base de datos va a lla"ar a un "étodo créate&(.

DAO #onsiste b*sica"ente en una clase que es la que interact+a con la basede datos.

os "étodos de esta clase dependen de la aplicación ' de lo que quera"oshacer.

Ventajas os Ob)etos de Acceso a Datos son un Patrón de los subordinados de Diseño #ore - EE '

considerados una buena practica. a venta)a de usar ob)etos de acceso a datos es quecualquier ob)eto de negocio &aquel que contiene detalles espec/ icos de operación oaplicación( no requiere conoci"iento directo del destino inal de la in or"ación que"anipula.

os Ob)etos de Acceso a Datos pueden usarse en -ava para aislar a una aplicación de la

tecnolog/a de persistencia -ava sub'acente &API de Persistencia -ava(, la cual podr/a ser

-D0#, -DO, Enterprise -ava0eans, 1op in2, 3ibernate, i0A1I4, o cualquier otra tecnolog/ade persistencia. %sando Ob)etos de Acceso de Datos signi ica que la tecnolog/asub'acente puede ser actualizada o ca"biada sin ca"biar otras partes de la aplicación.

Desventajas

a le5ibilidad tiene un precio. #uando se añaden DAOs a una aplicación, la co"ple)idad

adicional de usar otra capa de persistencia incre"enta la cantidad de código e)ecutadodurante tie"po de e)ecución. a con iguración de las capas de persistencia requiere en la"a'or/a de los casos "ucho traba)o.

as aplicaciones cr/ticas con el rendi"iento no deber/an usar DAOs.

El Patrón MVC (Modelo Vista Controlador)

El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que

separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres

componentes distintos (Modelo, Vista y Controlador). El Patrón MVC se e

frecuentemente en aplicaciones !e", donde la Vista es la p#gina $%M& y el código quepro ee de datos din#micos a la p#gina' el Modelo es el istema de estión de *ase de

http://es.wikipedia.org/wiki/J2EE

http://es.wikipedia.org/wiki/J2EE



+atos y la &ógica de negocio' el Controlador es el responsa"le de reci"ir los e entos de

entrada desde la Vista.

n modelo puede tener di ersas istas, cada una con su correspondiente controlador.

n e-emplo cl#sico es el de la información de una "ase de datos, que se puede

presentar de di ersas formas diagrama de tarta, de "arras, ta"ular, etc. Veamos cada

componente.

Modelo

Es la representación espec/fica de la información con la cual el sistema opera. &a lógica

de datos asegura la integridad de estos y permite deri ar nue os datos' por e-emplo, no

permitiendo comprar un n0mero de unidades negati o, o calculando los totales e

impuestos del carrito de compra. Esto quiere decir que aqu/ se operan los datos y las

reglas de negocio asociadas al sistema,

incluyendo el an#lisis sint#ctico y el procesamiento de los datos de entrada y

de los datos de salida.

El Modelo es el responsa"le de

• 1cceder a la capa de almacenamiento de datos. &o ideal es que el modelo sea

independiente del sistema de almacenamiento.

• +efine las reglas de negocio (la funcionalidad del sistema). n e-emplo de regla

puede ser 2 i la mercanc/a pedida no est# en el almac3n, consultar el tiempo de entrega

est#ndar del pro eedor4.

• &le a un registro de las istas y controladores del sistema.

• i estamos ante un modelo acti o, notificar# a las istas los cam"ios que en los

datos pueda producir un agente e5terno (por e-emplo, un fic6ero "atc6 que actualiza los

datos, un temporizador que desencadena una inserción, etc.). n e-emplo de MVC con un

modelo pasi o (aquel que no notifica cam"ios en los datos) es la na egación we", que

responde a las entradas del usuario, pero no detecta los cam"ios en datos del ser idor.

Vista



Este presenta el Modelo, usualmente la interfaz de usuario. &a ista es la capa de la

aplicación que e el usuario en un formato adecuado para interactuar, en otras pala"ras,

es nuestra interfase grafica.

&as vistas son responsa"les de

• 7eci"ir datos del modelo y los muestra al usuario.

• %ienen un registro de su controlador asociado (normalmente porque adem#s lo

instancia).

• Pueden dar el ser icio de 21ctualización()4, para que sea in ocado por el controlador

o por el modelo (cuando es un modelo acti o que informa de los cam"ios en los datos

producidos por otros agentes).

Controlador

El Controlador es la capa que controla todo lo que puede realizar nuestra aplicación.

7esponde a e entos, usualmente acciones del usuario e in oca cam"ios en el modelo y

pro"a"lemente en la ista. Est# compuesto por acciones que se representan con

funciones en una clase. Por e-emplo, yo tengo mi controlador llamado 2Clientes4, y este

controlador puede realizar las acciones 2Crear4,4Editar4,4&istar4 entre otras.

El controlador es responsa"le de

• 7eci"e los e entos de entrada (un clic, un cam"io en un campo de te5to, etc.).

• Contiene reglas de gestión de e entos, del tipo 2 8 E ento 9, entonces 1cción !4.

Estas acciones pueden suponer peticiones al modelo o a las istas. na de estas peticiones

a las istas puede ser una llamada al m3todo 21ctualizar()4. na petición al modelo puede

ser 2:"tener;tiempo;de;entrega( nue a;orden;de; enta )4.

El diagrama de secuencia



Pasos

<. El usuario introduce el e ento.

=. El Controlador reci"e el e ento y lo traduce en una petición al Modelo (aunque

tam"i3n puede llamar directamente a la ista).

>. El modelo (si es necesario) llama a la ista para su actualización.

?. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.

@. El Controlador reci"e el control.

Ventajas y Desventajas

&a popularidad de este diseAo se de"e mas que todo a que es muc6o mas f#cil

organizar aplicaciones grandes.

&as enta-as

• Clara separación entre interfaz, lógica de negocio y de presentación, que adem#s

pro oca parte de las enta-as siguientes.

• encillez para crear distintas representaciones de los mismos datos.

• Bacilidad para la realización de prue"as unitarias de los componentes, as/ como de

aplicar desarrollo guiado por prue"as (%++).

• 7eutilización de los componentes.

• implicidad en el mantenimiento de los sistemas.

• Bacilidad para desarrollar prototipos r#pidos.

• &os desarrollos suelen ser m#s escala"les.

&as des enta-as

• %ener que ceAirse a una estructura predefinida, lo que a eces puede incrementar la

comple-idad del sistema. $ay pro"lemas que son m#s dif/ciles de resol er respetando el

patrón MVC.

• &a cur a de aprendiza-e para los nue os desarrolladores se estima mayor que la de

modelos m#s simples como !e"forms.

• &a distri"ución de componentes o"liga a crear y mantener un mayor n0mero de

fic6eros.

Ejemplo



*ien, pero esto cómo se implementaD E5iste una pequeAa dificultad la mayor parte de

las 6erramientas de desarrollo incorporan en las clases de la ista gran parte o todo el

procesamiento de e entos. Con lo que el controlador queda semioculto dentro de la

ista. 1 pesar de ello, podemos acercarnos "astante al patrón.

Modelo

n e-emplo de la ida real de un Modelo seria una clase llamada Cliente, la cual tiene

las mismas propiedades de una ta"la cliente en mi "ase de datos

Controlador

n Controlador seria el Controlador Cliente, generalmente las clases Controladoras

lle an el sufi-o 2Controlador4, as/ que en nuestro caso se llamar/a ClientesControlador.

El controlador lle ar/a las acciones que nosotros podemos realizar en un cliente comopor e-emplo, agregar, "orrar, modificar, agregar orden, etc.

Vista

&a Vista es el mas f#cil de entender, simplemente es nuestra pagina 6tml. 1 tra 3s de la

acción del Controlador especificamos a que ista queremos en iar el resultado de la

acción del Controlador. En algunos casos es necesario pasar información a la Vista desde

el Controlador, esto se logra f#cilmente en el código de la acción.

Venta-as y des enta-as del uso del patrón

e tienen muc6as enta-as como

• &a implementación se realiza de forma modular.• us istas muestran información actualizada siempre. El programador no de"e

preocuparse de solicitar que las istas se actualicen, ya que este proceso es realizadoautom#ticamente por el modelo de la aplicación.

• Cualquier modificación que afecte al dominio, como aumentar m3todos o datos

contenidos, implica una modificación sólo en el modelo y las interfaces del mismo con las istas,no todo el mecanismo de comunicación y de actualización entre modelos.



• &as modificaciones a las istas no afectan al modelo de dominio, simplemente se modificala representación de la información, no su tratamiento.

• MVC esta demostrando ser un patrón de diseAo "ien ela"orado pues las aplicaciones que

lo implementan presentan una e5tensi"ilidad y una manteni"ilidad 0nicas comparadas con otrasaplicaciones "asadas en otros patrones.

Como des enta-as tenemos

• Para desarrollar una aplicación "a-o el patrón de diseAo MVC es necesario una mayordedicación en los tiempos iniciales del desarrollo. ormalmente el patrón e5ige al programadordesarrollar un mayor n0mero de clases que, en otros entornos de desarrollo, no son necesarias.

in em"argo, esta des enta-a es muy relati a ya que posteriormente, en la etapa demantenimiento de la aplicación, una aplicación MVC es muc6o m#s manteni"le, e5tensi"le ymodifica"le que una aplicación que no lo implementa.

• MVC requiere la e5istencia de una arquitectura inicial so"re la que se de"en construirclases e interfaces para modificar y comunicar los módulos de una aplicación. Esta arquitectura

inicial de"e incluir, por lo menos, un mecanismo de e entos para poder proporcionar lasnotificaciones que genera el modelo de aplicación' una clase Modelo, otra clase Vista y una claseControlador gen3ricas que realicen todas las tareas de comunicación, notificación y actualizaciónque ser#n luego transparentes para el desarrollo de la aplicación.

• MVC es un patrón de diseAo orientado a o"-etos por lo que su implementación essumamente costosa y dif/cil en lengua-es que no siguen este paradigma.

Documents

Data Access Object