Diferencia entre el patrón de repositorio y DAO en Java

1. Patrón de objeto de acceso a datos
2. Patrón de repositorio
3. Diferencia entre el objeto de acceso a datos (DAO) y los patrones de repositorio en Java
4. Diferencia entre la DAO y la implementación de patrones de repositorio

Hoy aprenderemos sobre el objeto de acceso a datos (DAO) y los patrones de repositorio. Este artículo también educa sobre las diferencias entre ellos.

Patrón de objeto de acceso a datos

Este patrón es la abstracción de la persistencia de datos, también considerado más cercano al almacenamiento subyacente, que se centra principalmente en tablas. Es por eso que, la mayoría de las veces, los objetos de acceso a datos (DAO) coinciden con las tablas de la base de datos, lo que permite el método más directo para recuperar y enviar datos desde el almacenamiento mientras se ocultan las consultas desagradables.

Patrón de repositorio

Un patrón de repositorio es un procedimiento para recuperar datos almacenados de nuestra aplicación que oculta todos los aspectos de un sistema de almacenamiento de datos. A continuación se muestra la interfaz del repositorio que nos permite buscar un usuario por su nombre de usuario.

interface UserRepository {
  User findUserByUsername(Username name);
}

Esto puede tener una o varias implementaciones basadas en nuestra tecnología de almacenamiento, por ejemplo, MySQL, Amazon DynamoDB, Web Service, Oracle u otros.

También podemos decir que el patrón de repositorio es un patrón de diseño que aísla la fuente de datos del resto de una aplicación. El repositorio media entre las fuentes de datos (como servicios web y modelos persistentes) y el resto de una aplicación.

A continuación se muestra la representación gráfica del uso del patrón del repositorio.

Comprende bien que el repositorio es similar al Objeto de acceso a datos (DAO), pero una abstracción que oculta toda la lógica que se utiliza para recuperar los datos de la lógica empresarial.

Se comporta como un envoltorio alrededor del modelo y es responsable de acceder a los datos de un almacén persistente. El beneficio de usar un repositorio es que separa los detalles precisos de cómo se almacenarán nuestras cosas de la aplicación que las está usando.

Esto es extremadamente importante para las pruebas porque podemos escribir un código auxiliar que siempre devolverá un User pero no accederá a la base de datos. Nos libera de varios problemas y nos permite escribir la prueba unitaria rápida para el código de nuestra aplicación, que no dependerá de los datos almacenados.

Diferencia entre el objeto de acceso a datos (DAO) y los patrones de repositorio en Java

La principal diferencia es que el repositorio devuelve los objetos solo que son comprensibles para una capa de llamada. En su mayoría, el repositorio es utilizado por una capa empresarial y, por lo tanto, genera los objetos comerciales.

Por otro lado, el objeto de acceso a datos devuelve los datos que pueden o no ser el objeto comercial completo. Significa que los datos no son un concepto comercial válido.

Si nuestros objetos comerciales son solo las estructuras de datos, entonces puede indicar que tenemos un problema de modelado. Significa un mal diseño, mientras que un repositorio tendrá más sentido con al menos objetos encapsulados correctamente.

Si solo estamos cargando o guardando las estructuras de datos, lo más probable es que no necesitemos tener un repositorio. El Mapeo relacional de objetos (ORM) es suficiente.

Un patrón de repositorio es la mejor solución si tenemos que tratar con un objeto comercial compuesto por varios otros objetos (un agregado), y este objeto específico requiere que todas sus partes sean consistentes (raíz agregada).

Es porque abstrae la información de persistencia completa. Nuestra aplicación solicita solo un Producto, y el repositorio lo devuelve como un todo; no importa cuántas consultas/tablas se necesiten para restaurar un objeto.

Recuerde que el objeto comercial no es una entidad de asignación relacional de objetos (ORM). Puede ser desde un punto de vista técnico, pero considerando el diseño, uno modela las cosas comerciales y el otro modela las cosas de persistencia.

La mayoría de las veces, no hay compatibilidad directa.

Aquí hay algunas situaciones en las que preferimos usar un patrón de repositorio:

• Se usa en un Sistema donde tenemos muchas consultas pesadas.
• Utilizamos patrones de repositorio para evitar consultas duplicadas.
• Se utiliza entre el Almacenamiento de datos y los dominios (entidad).
• También se utiliza para buscar y eliminar un elemento utilizando la especificación de la entidad para la que se crea el repositorio.

Ahora, entendamos esta diferencia a través de la implementación del código.

Diferencia entre la DAO y la implementación de patrones de repositorio

Comencemos con la implementación del patrón Objeto de acceso a datos.

Implementación de patrones de objetos de acceso a datos

Aquí, necesitamos tener tres clases que se enumeran a continuación:

1. Una clase de dominio básica Employee
2. La interfaz EmployeeDAO que proporciona operaciones CRUD sencillas para un dominio Employee
3. Una clase EmployeeDAOImplementation que implementa la interfaz EmployeeDAO

Código de ejemplo (Clase Employee):

public class Employee {
  private Long id;
  private String employeeCode;
  private String firstName;
  private String email;

  // write your getters/setters
}

Código de ejemplo (interfaz EmployeeDAO):

public interface EmployeeDAO {
  void create(Employee employee);
  Employee read(Long id);
  void update(Employee employee);
  void delete(String employeeCode);
}

Código de ejemplo (clase EmployeeDAOImplementation):

public class EmployeeDAOImplementation implements EmployeeDAO {
  private final EntityManager entityManager;

  @Override
  public void create(Employee employee) {
    entityManager.persist(employee);
  }

  @Override
  public Employee read(long id) {
    return entityManager.find(Employee.class, id);
  }

  // ... continue with remaining code
}

Estamos usando la interfaz JPA EntityManager para comunicarnos con el almacenamiento subyacente. Además, proporcione el mecanismo de acceso a los datos para el dominio Employee.

Implementación de patrones de repositorio

Este patrón encapsula el almacenamiento, el comportamiento de búsqueda y la recuperación, simulando la colección de objetos. Al igual que DAO, también oculta consultas y maneja datos, pero se encuentra en un nivel superior más cercano a la lógica comercial de la aplicación.

Un repositorio también puede usar el DAO para obtener los datos de una base de datos. Además, puede llenar el objeto de dominio o preparar datos del dominio y luego enviarlos al sistema de almacenamiento usando DAO para persistencia.

Aquí, necesitamos las siguientes clases:

1. Una interfaz EmployeeRepository.
2. Una clase EmployeeRepositoryImplementation.

Código de ejemplo (interfaz EmployeeRepository):

public interface EmployeeRepository {
  Employee get(Long id);
  void add(Employee employee);
  void update(Employee employee);
  void remove(Employee employee);
}

Código de ejemplo (clase EmployeeRepositoryImplementation):

public class EmployeeRepositoryImplementation implements EmployeeRepository {
  private EmployeeDAOImplementation employeeDAOImplementation;

  @Override
  public Employee get(Long id) {
    Employee employee = employeeDAOImplementation.read(id);
    return employee;
  }

  @Override
  public void add(Employee employee) {
    employeeDAOImplementation.create(employee);
  }

  // ... continue with remaining code
}

Aquí, usamos la EmployeeDAOImplementation para recuperar/enviar datos desde una base de datos. Entonces, podemos decir que la implementación del repositorio y DAO se ven similares.

Es porque la clase Employee es el dominio anémico y un repositorio es solo una capa más sobre la capa de acceso a datos (DAO); sin embargo, un repositorio es la mejor manera de implementar el caso de uso empresarial. En comparación, el objeto de acceso a datos parece un buen candidato para acceder a los datos.