Patrón de diseño DAO y utilizándolo en varias tablas

Question

Estoy buscando comentarios sobre el patrón de diseño Data Access Object y utilizándolo cuando tiene que acceder a los datos en varias tablas. Parece que ese patrón, que tiene un DAO para cada tabla junto con un objeto de transferencia de datos (DTO) que representa una única fila, no es demasiado útil para tratar datos de múltiples tablas. Estaba pensando en crear un DAO compuesto y una DTO correspondiente que devolviera el resultado de, digamos, realizar una unión en dos tablas. De esta forma puedo usar SQL para captar todos los datos en lugar de obtener datos de uno usando un DAO y de la segunda tabla usando el segundo DAO, y compilarlos juntos en Java.

¿Existe una solución mejor? Y no, no puedo moverme a Hibernate u otra herramienta ORM en este momento. JDBC solo directamente para este proyecto.

Answer 1

Estoy de acuerdo con su enfoque. Mis DAO tienden a alinearse más en el nivel del objeto, en lugar de desde la perspectiva de la tabla DB. Puedo administrar más de un objeto a través de un DAO, pero es muy probable que estén estrechamente relacionados. No hay ninguna razón para no tener SQL accediendo a dos tablas que viven en un DAO.

Y para el registro, he desterrado el acrónimo DTO de mi vocabulario y código.

Answer 2

Idealmente, la forma de almacenar sus datos en una base de datos, y luego cómo acceder a ellos, debe derivar de la naturaleza de la relación entre las entidades de dominio en su modelo de dominio. Es decir, el modelo relacional debe seguir del modelo de dominio. Por ejemplo, si tiene dos entidades, por ejemplo, Usuario y Dirección.

Escenario # 1: La dirección nunca se accede de forma independiente, siempre son un atributo del usuario. En este caso, la dirección es un objeto de valor y el usuario es una entidad, y hay guías sobre cómo almacenar esta relación. Una forma es almacenar los atributos de dirección de la dirección junto a los atributos del usuario, en una sola tabla. En este caso, UserDao manejará ambos objetos.

Escenario n.º 2: La dirección se puede asociar a un usuario, pero también se puede separar por sí misma, una entidad. En este caso, se necesita un enfoque diferente al primero. Puede tener un DAO y una tabla separados para el tipo de Dirección.

Mi punto es que con mayor frecuencia se ignora esta importante idea de que el Modelo de dominio debe ser el núcleo de la aplicación, impulsando otras capas. Por ejemplo, si su modelo de dominio está definido correctamente y usted es consciente del tipo de entidades que posee y de la relación entre ellas, entonces su persistencia (tablas relacionales y sus relaciones, sus DAO, etc.) evolucionará como una consecuencia muy lógica de lo que tienes en el modelo de dominio.

En otras palabras, si pasa algún tiempo estudiando su modelo, podrá rastrear su problema para determinar cómo organizar sus DAO en un lugar en el modelo de dominio. Si puede definir claramente el tipo de objetos y la naturaleza de la relación entre ellos en el modelo de dominio, lo ayudará a resolver su problema en la capa DAL.