Catálogo de Patrones de Diseño J2EE. Y II: Capas de Negocio y de Integración

El acceso a los datos var�a dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, como una base de datos, var�a en gran medida dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc.) y de la implementaci�n del vendedor.

�Problema

Muchas aplicaciones de la plataforma J2EE en el mundo real necesitan utilizar datos persistentes en alg�n momento. Para muchas de ellas, este almacenamiento persistente se implementa utilizando diferentes mecanismos, y hay marcadas diferencias en los APIS utilizados para acceder a esos mecanismos de almacenamiento diferentes. Otras aplicaciones podr�an necesitar acceder a datos que residen en sistemas diferentes. Por ejemplo, los datos podr�an residir en sitemas mainframe, repositorios LDAP, etc. Otro ejemplo es donde los datos los proporcionan servicios a trav�s de sistemas externos como los sistemas de integraci�n negocio-a-negocio (B2B), servicios de tarjetas de cr�dito, etc.

Normalmente, las aplicaciones utilizan componentes distribuidos y compartidos como los beans de entidad para representar los datos persistentes. Se considera que una aplicaci�n emplea consistencia manejada por el bean (BMP) cuando sus beans de entidad acceden expl�citamente al almacenamiento persistente -- el bean de entidad incluye c�digo para hacer esto. Una aplicaci�n con requerimientos sencillos podr�a por lo tanto utilizar beans de entidad en lugar de beans de sesi�n o servlets para acceder al almacenamiento persistente y recuperar o modificar los datos. O, la aplicaci�n podr�a usar beans de entidad con persistencia manejada por el contenedor, y as� dejar que el contenedor maneje los detalles de las transaciones y de la persistencia.

Las aplicaciones pueden utilizar el API JDBC para acceder a los datos en un sistema de control de bases de datos relacionales (RDBMS). Este API permite una forma est�ndar de acceder y manipular datos en un almacenamineto persistente, como una base de datos ralacional. El API JDBC permite a las aplicaciones J2EE utilizar sentencias SQL, que son el m�todo est�ndar para acceder a tablas RDBMS. Sin embargo, incluso dentro de un entorno RDBMS, la s�ntaxis y formatos actuales de las sentencias SQL podr�an variar dependiendo de la propia base de datos en particular.

Incluso hay una mayor variaci�n con diferentes tipos de almacenamientos persistentes. Los mecanimos de acceso, los APIs soportados, y sus caracter�sticas varian entre los diferentes tipos de almacenamientos persistentes, como bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc. Las aplicaciones que necesitan acceder a datos de un sistema legal o un sistema dispar (como un mainframe o un servicio B2B) se ven obligados a utilizar APIs que podr�an ser propietarios. Dichas fuentes de datos dispares ofrecen retos a la aplicaci�n y potencialmente pueden crear una dependencia directa entre el c�digo de la aplicaci�n y el c�digo de acceso a los datos. Cuando los componentes de negocio -- beans de entidad, beans de sesi�n e incluso componentes de presentaci�n como servlets y beans de apoyo para p�ginas JSP -- necesitan acceder a una fuente de datos, pueden utilizar el API apropiado para conseguir la conectividad y manipular la fuente de datos. Pero introducir el c�digo de conectividad y de acceso a datos dentro de estos componentes genera un fuerte acoplamiento entre los componentes y la implementaci�n de la fuente de datos. Dichas dependencias de c�digo en los componentes hace dif�cil y tedioso migrar la aplicaci�n de un tipo de fuente de datos a otro. Cuando cambia la fuente de datos, tambi�n deben cambiar los componentes para manejar el nuevo tipo de fuente de datos.

�Causas

Los componentes como los beans de entidad controlados por el bean, los beans de sesi�n, los servlets, y otros objetos como beans de apoyo para p�ginas JSP necesitan recuperar y almacenar informaci�n desde almacenamientos persistentes y otras fuentes de datos como sistemas legales, B2B, LDAP, etc.
Los APIs para almacenamiento persistente var�an dependiendo del vendedor del producto. Otras fuentes de datos podr�an tener APIS que no son est�ndar y/o propietarios. Estos APIs y sus capacidades tambi�n var�an dependiendo del tipo de almacenamiento -- bases de datos relacionales, bases de datos orientadas a objetos, documentos XML, ficheros planos, etc. Hay una falta de APIs uniformes para corregir los requrimientos de acceso a sistemas tan dispares.
Los componentes normalmente utilizan APIs propietarios para acceder a sistemas externos y/o legales para recuperar y almacenar datos.
La portabilidad de los componentes se ve afectada directamente cuando se incluyen APIs y mecanismos de acceso espec�ficos.
Los componentes necesitan ser transparentes al almacenamiento persistente real o la implementaci�n de la fuente de datos para proporcionar una migraci�n sencilla a diferentes productos, diferentes tipos de almacenamiento y diferentes tipos de fuentes de datos.

�Soluci�n

Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexi�n con la fuente de datos para obtener y almacenar datos.

El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. Esta fuente de datos puede ser un almacenamiento persistente como una RDMBS, un servicio externo como un intercambio B2B, un repositorio LDAP, o un servicio de negocios al que se accede mediante CORBA Internet Inter-ORB Protocol (IIOP) o sockets de bajo nivel. Los componentes de negocio que tratan con el DAO utilizan un interface simple expuesto por el DAO para sus clientes. El DAO oculta completamente los detalles de implementaci�n de la fuente de datos a sus clientes. Como el interface expuesto por el DAO no cambia cuando cambia la implementaci�n de la fuente de datos subyacente, este patr�n permite al DAO adaptarse a diferentes esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de engocio. Esencialmente, el DAO act�a como un adaptador entre el componente y la fuente de datos.

�Estructura

La siguiente figura muestra el diagrama de clases que representa las relaciones para el patr�n DAO:

�Participantes y Responsabilidades

La siguiente figura muestra el diagrama de secuecnia de la interacci�n entre los distintos participantes en este patr�n:

�BusinessObject

BusinessObject representa los datos del cliente. Es el objeto que requiere el acceso a la fuente de datos para obtener y almacenar datos. Podr�amos implementar un BusinessObject como un bean de sesi�n, un bean de entidad o cualquier otro objeto Java, adem�s de como un Servlet o como un bean de apoyo.

�DataAccessObject

DataAccessObject es el objeto principal de este patr�n. DataAccessObject abstrae la implementaci�n del acceso a datos subyacente al BusinessObject para permitirle un acceso transparente a la fuente de datos. El BusinessObject tambi�n delega las operaciones de carga y almacenamiento en el DataAccessObject.

�DataSource

Representa la implementaci�n de la fuente de datos. Una fuente de datos podr�a ser una base de datos como un RDBMS, un OODBMS, un repositorio XML, un fichero plano, etc. Tambi�n lo pueden ser otros sitemas (mainframes/legales), servicios (servicio B2B u oficina de tarjetas de cr�dito), o alg�n tipo de repositorio (LDAP).

�TransferObject

Representa un Transfer Object utilizado para el transporte de datos. DataAccessObject podr�a utilizar un Transfer Object para devolver los datos al cliente. El DataAccessObject tambi�n podr�a recibir datos desde el cliente en un Transfer Object para actualizar los datos en la fuente de datos.

�Estrategias

�Automatic DAO Code Generation

Como cada BusinessObject corresponde a un DAO espec�fico, es posible establecer relaciones entre el BusinessObject, el DAO, y las implementaciones subyacentes (como en las tablas de una RDBMS). Una vez que se han establecido las relaciones, es posible escribir una utilidad de generaci�n-de-c�digo-espec�fica-de-aplicaci�n que genere el c�digo para todos los DAOs que necesita la aplicaci�n. Los metadatos para generar el DAO pueden venir de un fichero descriptor definido por el desarrollador. Como alternativa, el generador de c�digo puede inspeccionar la base de datos y proporcionar los DAOs necesarios para acceder a ella.

Si los requerimientos de los DAOs son lo suficientemente complejos, debemos considerar la utilizaci�n de herramientas de terceras partes que proporcionan un mapeo de objeto-a-relacional para bases de datos RDBMS. Estas herramientas normalmente incluyen utilidades GUI para mapear los objetos de negocio a objetos de almacenamiento persistente y adem�s definir los DAOs intermedios. Estas herramientas generan el c�digo autom�ticamente una vez que se termina el mapeo, y podr�an proporcionar otras caracter�sticas valiosas como el cach� de resultados y de consultas, integraci�n con servidores de aplicaciones, integraci�n con otros productos de terceras partes, etc.

�Factory for Data Access Objects

El patr�n DO se puede flexibilizar adoptando los patrones Abstract Factory [GoF] y Factory Method [GoF].

Cuando el almacenamiento subyacente no est� sujeto a cambios de una implemantaci�n a otra, esta estrategia se puede implementar utilizando el patr�n Factory Method para producir el n�mero de DAOs que necesita la aplicaci�n. En la siguiente figura podemos ver el diagrama de clases para este caso:

Cuando el almacenamiento subyacente si est� sujeto a cambios de una implementaci�n a otra, esta estrategia se podr�a implementar usando el patr�n Abstract Factory. Este patr�n a su vez puede construir y utilizar la implementaci�n Factory Method. En este caso, esta estrategia proporciona un objeto factor�a abstracta de DAOs (Abstract Factory) que puede construir varios tipos de factor�as concretas de DAOs, cada factor�a soporta un tipo diferente de implementaci�n del almacenamiento persistente. Una vez que obtenemos la factor�a concreta de DAOs para una implementaci�n espec�fica, la utilizamos para producir los DAOs soportados e implementados en esa implementaci�n.

En la siguiente figura podemos ver el diagrama de clases para esta estrategia. En �l vemos una factor�a base de DAOs, que es una clase abstracta que extienden e implementan las diferentes factor�as concretas de DAOs para soportar el acceso espec�fico a la implementaci�n del almacenamiento. El cliente puede obtener una implementaci�n de la factor�a concreta del DAO como una RdbDAOFactory y utilizarla para obtener los DAOs concretos que funcionan en la implementaci�n del almacenamiento. Por ejemplo, el cliente puede obtener una RdbDAOFactory y utilizarlas para obtener DAOs espec�fcios como RdbCustomerDAO, RdbAccountDAO, etc. Los DAOs pueden extender e implementar una clase base gen�rica (mostradas como DAO1 y DAO2) que describa espec�ficamente los requerimientos del DAO para el objeto de negocio que soporta. Cada DAO concreto es responsable de conectar con la fuente de datos y de obtener y manipular los datos para el objeto de negocio que soporta.

En la siguiente figura podemos ver el diagrama de secuencia para esta estrategia:

�Consecuencias

Permite la Transpariencia
Los objetos de negocio puede utilizar la fuente de datos sin conocer los detalles espec�ficos de su implementaci�n. El acceso es transparente porque los detalles de la implementaci�n se ocultan dentro del DAO.
Permite una Migraci�n m�s F�cil
Una capa de DAOs hace m�s f�cil que una aplicaci�n pueda migrar a una implementaci�n de base de datos diferente. Los objetos de negocio no conocen la implementaci�n de datos subyacente, la migraci�n implica cambios s�lo en la capa DAO. Adm�s, si se emplea la estrategia de factor�as, es posible proporcionar una implementaci�n de factor�as concretas por cada implementaci�n del almacenamiento subyacente. En este caso, la migraci�n a un almacenamiento diferente significa proporcionar a la aplicaci�n una nueva implementaci�n de la factor�a.
Reduce la Complejidad del C�digo de los Objetos de Negocio
Como los DAOs manejan todas las complejidades del acceso a los datos, se simplifica el c�digo de los objetos de negocio y de otros clientes que utilizan los DAOs. Todo el c�digo relacionado con la implementaci�n (como las sentencias SQL) est�n dentro del DAO y no en el objeto de negocio. Esto mejora la lectura del c�digo y la productividad del desarrollo.
Centraliza Todos los Accesos a Datos en un Capa Indenpendinte
Como todas las operaciones de acceso a los datos se ha delegado en los DAOs, esto se puede ver como una capa que aisla el resto de la aplicaci�n de la implementaci�n de acceso a los datos. Esta centralizaci�n hace que la aplicaci�n sea m�s sencilla de mantener y de manejar.
No es �til para Persistencia Manejada por el Contenedor
Como el contenedor EJB maneja los beans de entidad con persistencia manejada por el contenedor (CMP), sirve autom�ticamente todo el acceso al almacenamiento persistente. Las aplicaci�n que utilizan este tipo de beans no necesitan la capa DAO, ya que el servidor de aplicaciones proporciona de forma transparente esta funcionalidad. Sin embargo, los DAOS a�n son �tiles cuando se necesita una combinaci�n de CMP (para beans de entidad) y BMP (para beans de sei�n, servlets).
A�ade una Capa Extra
Los DAOs crean un capa de objetos adicional entre el cliente y la fuente de datos que necesitamos dise�ar e implementar para obtener los beneficios de este patr�n. Pero para obtener estos beneficios debemos pagarlos con un esfuerzo adicional.
Necesita Dise�ar un �rbol de Clases
Cuando se utiliza una estrategia de factor�as, necesitamos dise�ar e implementar el �rbol de factor�as concretas y el �rbol de productos concretos producidos por las factor�as. Necesitamos justificar este esfuerzo adicional para ver si merece la pena dicha flexibilidad. Esto incrementa la complejidad del dise�o. Sin embargo, podemos elegir la implementaci�n de la estrategia de factor�as empezando primero con el patr�n Factory Method, y luego avanzar hasta el patr�n Abstract Factory si es necesario.

�C�digo de Ejemplo

�Implementar el Patr�n Data Access Object

Abajo podemos ver el c�digo de un DAO de ejemplo para un objeto persistente que representa informaci�n de un cliente. CloudscapeCustomerDAO crea un Transfer Object Customer cuando se llama al m�todo findCustomer():


// CloudscapeCustomerDAO implementation of the 
// CustomerDAO interface. This class can contain all
// Cloudscape specific code and SQL statements. 
// The client is thus shielded from knowing 
// these implementation details.

import java.sql.*;

public class CloudscapeCustomerDAO implements 
    CustomerDAO {
  
  public CloudscapeCustomerDAO() {
    // initialization 
  }

  // The following methods can use
  // CloudscapeDAOFactory.createConnection() 
  // to get a connection as required

  public int insertCustomer(...) {
    // Implement insert customer here.
    // Return newly created customer number
    // or a -1 on error
  }
  
  public boolean deleteCustomer(...) {
    // Implement delete customer here
    // Return true on success, false on failure
  }

  public Customer findCustomer(...) {
    // Implement find a customer here using supplied
    // argument values as search criteria
    // Return a Transfer Object if found,
    // return null on error or if not found
  }

  public boolean updateCustomer(...) {
    // implement update record here using data
    // from the customerData Transfer Object
    // Return true on success, false on failure or
    // error
  }

  public RowSet selectCustomersRS(...) {
    // implement search customers here using the
    // supplied criteria.
    // Return a RowSet. 
  }

  public Collection selectCustomersTO(...) {
    // implement search customers here using the
    // supplied criteria.
    // Alternatively, implement to return a Collection 
    // of Transfer Objects.
  }
  ...
}

Abajo podemos ver el c�digo para utilizar este DAO:


...
// create the required DAO Factory
DAOFactory cloudscapeFactory =   
  DAOFactory.getDAOFactory(DAOFactory.DAOCLOUDSCAPE);

// Create a DAO
CustomerDAO custDAO = 
  cloudscapeFactory.getCustomerDAO();

// create a new customer
int newCustNo = custDAO.insertCustomer(...);

// Find a customer object. Get the Transfer Object.
Customer cust = custDAO.findCustomer(...);

// modify the values in the Transfer Object.
cust.setAddress(...);
cust.setEmail(...);
// update the customer object using the DAO
custDAO.updateCustomer(cust);

// delete a customer object
custDAO.deleteCustomer(...);
// select all customers in the same city 
Customer criteria=new Customer();
criteria.setCity("New York");
Collection customersList = 
  custDAO.selectCustomersTO(criteria);
// returns customersList - collection of Customer
// Transfer Objects. iterate through this collection to
// get values.

...

La siguiente figura representa el diagrama de clases para este ejemplo:

�Implementar la Estrategia Factory for Data Access Objects

�Utilizar el Patr�n Factory Method

Consideremos un ejemplo donde hemos implementado esta estrategia en la que una factor�a de DAOs produce muchos DAOs para una �nica implementaci�n de una base de datos (por ejemplo, Oracle). La factor�a produce DAOs como CustomerDAO, AccountDAO, OrderDAO, etc. Abajo podemos ver el diagrama de clases para este ejemplo:

Y aqu� tenemos el c�digo de ejemplo para la factor�a de DAOs (CloudscapeDAOFactory):


// Cloudscape concrete DAO Factory implementation
import java.sql.*;

public class CloudscapeDAOFactory extends DAOFactory {
  public static final String DRIVER=
    "COM.cloudscape.core.RmiJdbcDriver";
  public static final String DBURL=
    "jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB";

  // method to create Cloudscape connections
  public static Connection createConnection() {
    // Use DRIVER and DBURL to create a connection
    // Recommend connection pool implementation/usage
  }
  public CustomerDAO getCustomerDAO() {
    // CloudscapeCustomerDAO implements CustomerDAO
    return new CloudscapeCustomerDAO();
  }
  public AccountDAO getAccountDAO() {
    // CloudscapeAccountDAO implements AccountDAO
    return new CloudscapeAccountDAO();
  }
  public OrderDAO getOrderDAO() {
    // CloudscapeOrderDAO implements OrderDAO
    return new CloudscapeOrderDAO();
  }
  ...
}

�Utilizar el Patr�n Abstract Factory

Consideremos un ejemplo donde implementemos esta estrategia para tres bases de datos diferenets. En este caso, se puede emplear el patr�n Abstract Factory. En la siguiente figura podemos ver el diagrama de clases para este ejmplo.

El siguiente fragmento de c�digo muestra parte de la clase DAOFactory. Esta factor�a produce DAOs como CustomerDAO, AccountDAO, OrderDAO, etc. Esta estrategia utiliza el patr�n Factory Method en las factor�as producidas por el Abstract Factory.


// Abstract class DAO Factory
public abstract class DAOFactory {

  // List of DAO types supported by the factory
  public static final int CLOUDSCAPE = 1;
  public static final int ORACLE = 2;
  public static final int SYBASE = 3;
  ...

  // There will be a method for each DAO that can be 
  // created. The concrete factories will have to 
  // implement these methods.
  public abstract CustomerDAO getCustomerDAO();
  public abstract AccountDAO getAccountDAO();
  public abstract OrderDAO getOrderDAO();
  ...

  public static DAOFactory getDAOFactory(
      int whichFactory) {
  
    switch (whichFactory) {
      case CLOUDSCAPE: 
          return new CloudscapeDAOFactory();
      case ORACLE    : 
          return new OracleDAOFactory();      
      case SYBASE    : 
          return new SybaseDAOFactory();
      ...
      default           : 
          return null;
    }
  }
}

El ejemplo de c�digo para CloudscapeDAOFactory se ve en el siguiente listado. La implementaci�n para OracleDAOFactory y SybaseDAOFactory son similares excepto para especifidades de cada implementaci�n, como el driver JDBC, la URL de la base de datos, y diferencias en la s�ntaxis SQL, si existe-


// Cloudscape concrete DAO Factory implementation
import java.sql.*;

public class CloudscapeDAOFactory extends DAOFactory {
  public static final String DRIVER=
    "COM.cloudscape.core.RmiJdbcDriver";
  public static final String DBURL=
    "jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB";

  // method to create Cloudscape connections
  public static Connection createConnection() {
    // Use DRIVER and DBURL to create a connection
    // Recommend connection pool implementation/usage
  }
  public CustomerDAO getCustomerDAO() {
    // CloudscapeCustomerDAO implements CustomerDAO
    return new CloudscapeCustomerDAO();
  }
  public AccountDAO getAccountDAO() {
    // CloudscapeAccountDAO implements AccountDAO
    return new CloudscapeAccountDAO();
  }
  public OrderDAO getOrderDAO() {
    // CloudscapeOrderDAO implements OrderDAO
    return new CloudscapeOrderDAO();
  }
  ...
}

El interface CustomerDAO mostrado en el siguiente listado, define los m�todos DAO para los objetos Customer persistentes que son implementados por todas las implementaciones de DAOs concretos como CloudscapeCustomerDAO, OracleCustomerDAO, y SybaseCustomerDAO. Similares, aunque no se listan aqu�, son los interfaces AccountDAO y OrderDAO que definen los metodos DAO para los objetos de negocio Account y Order respectivamente.


// Interface that all CustomerDAOs must support
public interface CustomerDAO {
  public int insertCustomer(...);
  public boolean deleteCustomer(...);
  public Customer findCustomer(...);
  public boolean updateCustomer(...);
  public RowSet selectCustomersRS(...);
  public Collection selectCustomersTO(...);
  ...
}

CloudscapeCustomerDAO implementa CustomerDAO como se ven en el siguiente listado. La implementaci�n de los otros DAOs, como CloudscapeOrderDAO, OracleCustomerDAO, OracleAccountDAO, etc. son similares:

 
// CloudscapeCustomerDAO implementation of the 
// CustomerDAO interface. This class can contain all
// Cloudscape specific code and SQL statements. 
// The client is thus shielded from knowing 
// these implementation details.

import java.sql.*;

public class CloudscapeCustomerDAO implements 
    CustomerDAO {
  
  public CloudscapeCustomerDAO() {
    // initialization 
  }

  // The following methods can use
  // CloudscapeDAOFactory.createConnection() 
  // to get a connection as required

  public int insertCustomer(...) {
    // Implement insert customer here.
    // Return newly created customer number
    // or a -1 on error
  }
  
  public boolean deleteCustomer(...) {
    // Implement delete customer here
    // Return true on success, false on failure
  }

  public Customer findCustomer(...) {
    // Implement find a customer here using supplied
    // argument values as search criteria
    // Return a Transfer Object if found,
    // return null on error or if not found
  }

  public boolean updateCustomer(...) {
    // implement update record here using data
    // from the customerData Transfer Object
    // Return true on success, false on failure or
    // error
  }

  public RowSet selectCustomersRS(...) {
    // implement search customers here using the
    // supplied criteria.
    // Return a RowSet. 
  }

  public Collection selectCustomersTO(...) {
    // implement search customers here using the
    // supplied criteria.
    // Alternatively, implement to return a Collection 
    // of Transfer Objects.
  }
  ...
}

La clase Transfer Object Customer del siguiente listado la utilizan los DAOs para enviar y recibir datos desde los clientes. La utilizaci�n del patr�n Transfer Object se explica con m�s detalles en la p�gina Transfer Object:

 

public class Customer implements java.io.Serializable {
  // member variables
  int CustomerNumber;
  String name;
  String streetAddress;
  String city;
  ...

  // getter and setter methods...
  ...
}

El siguiente ejemplo muestra la utilizaci�n del factor�a de DAOs y del DAO, Si la implementaci�n cambiara de Cloudscape a otro producto, el �nico cambio que tendr�amos que hacer es que el m�todo getDAOFactory() llame a la factor�a adecuada.


...
// create the required DAO Factory
DAOFactory cloudscapeFactory =   
  DAOFactory.getDAOFactory(DAOFactory.DAOCLOUDSCAPE);

// Create a DAO
CustomerDAO custDAO = 
  cloudscapeFactory.getCustomerDAO();

// create a new customer
int newCustNo = custDAO.insertCustomer(...);

// Find a customer object. Get the Transfer Object.
Customer cust = custDAO.findCustomer(...);

// modify the values in the Transfer Object.
cust.setAddress(...);
cust.setEmail(...);
// update the customer object using the DAO
custDAO.updateCustomer(cust);

// delete a customer object
custDAO.deleteCustomer(...);
// select all customers in the same city 
Customer criteria=new Customer();
criteria.setCity("New York");
Collection customersList = 
  custDAO.selectCustomersTO(criteria);
// returns customersList - collection of Customer
// Transfer Objects. iterate through this collection to
// get values.

...

�Patrones Relacionados

Transfer Object
Un DAO utiliza Transfer Objects para transportar los datos desde y hacia sus clientes.
Factory Method [GoF] y Abstract Factory [GoF]
La Factor�a para la estrategia Data Access Objects usa el patr�n Factory Method para implementar las factor�as concretas y sus productos (DAOs). Para a�adir flexibilidad, se podr�a emplear el patr�n Abstract Factory como se explica en la secci�n de estrategias.
Broker [POSA1]
El patr�n DAO est� relacionado con el patr�n Broker, que describe aproximaciones para desacoplar clientes y servidores en sistemas distribuidos. El patr�n DAO aplica este patr�n espec�ficamente para desacoplar la capa de recursos de los clientes en otra capa, como las capas de negocio o presentaci�n.