Contexto
El acceso
a los datos varía dependiendo de la fuente de los datos. El acceso a
almacenamiento persistente, tal como a una base de datos, varía en gran medida
dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de
datos orientadas a objetos, archivos planos, y así sucesivamente) y la
aplicación de proveedor.
Problema
Muchos
en el mundo real Plataforma Java 2, Enterprise Edition (J2EE) necesitan
utilizar datos persistentes en algún momento. Para muchas aplicaciones,
almacenamiento persistente se realiza con diferentes mecanismos, y hay marcadas
diferencias en las API utilizadas para acceder a los diferentes mecanismos de
almacenamiento persistente. Otras aplicaciones pueden necesitar acceder a datos
que residen en sistemas separados. Por ejemplo, los datos pueden residir en los
sistemas mainframe, Protocolo de repositorios de acceso de directorio ligero
(LDAP), y así sucesivamente. Otro ejemplo es que los datos son proporcionados
por los servicios a través de sistemas externos como business-to-business
(B2B), integración de sistemas, servicios de oficinas de la carta de crédito,
etc.
Normalmente,
las aplicaciones utilizan componentes compartidos distribuidos como beans de
entidad para representar los datos persistentes. Una aplicación se considera el
empleo de frijol persistencia gestionada (BMP) para sus beans de entidad cuando
estos beans de entidad de acceso explícitamente el almacenamiento
persistente-el bean de entidad incluye un código para acceder directamente al
almacenamiento persistente. Una aplicación con requisitos simples puede
renunciar a utilizar beans de entidad y en su lugar utilizar beans de sesión o
servlets para acceder directamente al almacenamiento persistente para recuperar
y modificar los datos. O bien, la aplicación podría utilizar beans de entidad
con persistencia gestionada por contenedor, y así permitir que el contenedor de
manejar las transacciones y persistente detalles.
Las
aplicaciones pueden utilizar la API de JDBC para acceder a los datos que
residen en un sistema de gestión de bases de datos relacionales (RDBMS). La API
JDBC permite el acceso estándar y manipulación de datos en el almacenamiento
persistente, como una base de datos relacional. El API JDBC permite a las
aplicaciones J2EE utilizan sentencias SQL, que son el medio estándar para
acceder a tablas RDBMS. Sin embargo, incluso dentro de un entorno RDBMS, la
sintaxis y el formato real de las sentencias SQL pueden variar en función del
producto de base de datos en particular.
Fortalezas:
- Componentes tales como frijol gestionados beans de entidad, beans de sesión, servlets y otros objetos como ayudantes de las páginas JSP necesitan para recuperar y almacenar la información de los almacenes persistentes y otras fuentes de datos, como los sistemas de legado, B2B, LDAP, etc.
- APIs de almacenamiento persistente varían dependiendo del proveedor del producto. Otras fuentes de datos pueden tener las API que no son estándar y / o de propiedad. Estas API y sus capacidades también varían en función del tipo de almacenamiento RDBMS, sistema orientado a objetos de base de datos de gestión (SGBDOO), los documentos XML, archivos planos, etc. Hay una falta de uniforme APIs para hacer frente a los requisitos para acceder a este tipo de sistemas dispares.
- Componentes suelen utilizar las API patentada para acceder a sistemas externos y / o legado para recuperar y almacenar datos.
- Portabilidad de los componentes se ve afectada directamente cuando los mecanismos de acceso específicos y APIs están incluidos en los componentes.
- Los componentes deben ser transparentes para el almacenamiento persistente real o aplicación de origen de datos para facilitar la migración a diferentes productos de los proveedores, los diferentes tipos de almacenamiento, y los diferentes tipos de fuentes de datos.
Solución
Utilice
un objeto de acceso a datos (DAO) para abstraer y encapsular todos los accesos
a la fuente de datos. La DAO gestiona la conexión con la fuente de datos para
obtener y almacenar los datos.
El DAO
implementa el mecanismo de acceso requerido para trabajar con el origen de
datos. La fuente de datos puede ser un almacenamiento persistente como un
RDBMS, un servicio externo como un intercambio B2B, un repositorio como una
base de datos LDAP, o un servicio de negocio acceder a través de CORBA Internet
Inter-ORB Protocol (IIOP) o sockets de bajo nivel. El componente de negocio que
se basa en la DAO utiliza la interfaz más sencilla expuesta por la DAO para sus
clientes. El DAO oculta completamente los detalles de implementación de fuentes
de datos de sus clientes. Debido a que la interfaz expuesta por el DAO a los
clientes no cambia cuando cambia la implementación de fuentes de datos
subyacentes, este modelo permite que el DAO para adaptarse a los diferentes
esquemas de almacenamiento sin afectar a sus clientes o componentes de negocio.
Esencialmente, la DAO actúa como un adaptador entre el componente y la fuente
de datos.
Estructura
La figura 9.1 muestra el diagrama de clase que representa las relaciones para el patrón DAO
Figura 9.1 Los datos de acceso a objetos
Participantes
y Responsabilidades
Figura
9.2 contiene el diagrama de secuencia que muestra la interacción entre los
diferentes participantes en este patrón.
Figura
9.2 Acceso a datos de objetos diagrama de secuencia
BusinessObject
El
BusinessObject representa el cliente de datos. Es el objeto que requiere el
acceso a la fuente de datos para obtener y almacenar los datos. Un
BusinessObject puede ser implementado como un bean de sesión, bean de entidad,
o algún otro objeto de Java, además de un servlet o ayudante de frijol que
accede a la fuente de datos.
DataAccessObject
El
DataAccessObject es el objeto principal de este patrón. El DataAccessObject
abstrae la aplicación de acceso a datos subyacente para el
BusinessObject para permitir un acceso transparente a la fuente de datos. El
BusinessObject también delega la carga de datos y operaciones de la tienda a la
DataAccessObject.
Los objetos de negocio pueden utilizar la fuente de datos sin conocer los detalles específicos de la implementación del origen de datos. El acceso es transparente porque los detalles de implementación están ocultos en el interior del DAO.
·
Reduce la complejidad del código de
Business Objects Como el DAOs manejar todas
las complejidades de acceso a datos, simplifica el código de los objetos de
negocio y otros clientes de datos que utilizan el DAO. Todo
el código de la aplicación relacionada (como SQL) se encuentra en el DAO y no
en el objeto de negocio. Esto mejora la legibilidad del
código y la productividad en el desarrollo.
·
Centraliza todo acceso a datos en una
capa separada
Debido a que todas las operaciones de acceso a datos están ahora delegadas a la DAOs, la capa separada de acceso a datos puede ser visto como la capa que se puede aislar el resto de la aplicación de la aplicación de acceso a datos. Esta centralización hace que la aplicación más fácil de mantener y gestionar.
Debido a que todas las operaciones de acceso a datos están ahora delegadas a la DAOs, la capa separada de acceso a datos puede ser visto como la capa que se puede aislar el resto de la aplicación de la aplicación de acceso a datos. Esta centralización hace que la aplicación más fácil de mantener y gestionar.
·
Añade capa extra
El DAOs crear una capa adicional de objetos de datos entre el cliente y el origen de datos que deben ser diseñados e implementados para aprovechar los beneficios de este patrón. Sin embargo, el beneficio obtenido por la elección de este enfoque vale la pena el esfuerzo adicional.
El DAOs crear una capa adicional de objetos de datos entre el cliente y el origen de datos que deben ser diseñados e implementados para aprovechar los beneficios de este patrón. Sin embargo, el beneficio obtenido por la elección de este enfoque vale la pena el esfuerzo adicional.
(© 2001-2002 Sun
Microsystems, Inc. All Rights Reserved.)
No hay comentarios:
Publicar un comentario