Différence entre le modèle de référentiel et DAO en Java

1. Modèle Data Access Object
2. Modèle de référentiel
3. Différence entre l’objet d’accès aux données (DAO) et les modèles de référentiel en Java
4. Différence entre la mise en œuvre des modèles DAO et de référentiel

Aujourd’hui, nous allons en apprendre davantage sur les modèles d’objet d’accès aux données (DAO) et de référentiel. Cet article renseigne également sur les différences entre eux.

Modèle Data Access Object

Ce modèle est l’abstraction de la persistance des données, également considérée comme plus proche du stockage sous-jacent, qui est principalement centré sur les tables. C’est pourquoi, la plupart du temps, les objets d’accès aux données (DAO) correspondent aux tables de la base de données, permettant à la méthode la plus simple de récupérer et d’envoyer des données à partir du stockage tout en masquant les requêtes laides.

Modèle de référentiel

Un modèle de référentiel est une procédure pour récupérer les données stockées de notre application qui cache tous les aspects d’un système de stockage de données. Voici l’interface du référentiel qui nous permet de rechercher un user par son username.

interface UserRepository {
  User findUserByUsername(Username name);
}

Cela peut avoir une ou plusieurs implémentations basées sur notre technologie de stockage, par exemple, MySQL, Amazon DynamoDB, Web Service, Oracle ou autres.

Nous pouvons également dire que le modèle de référentiel est un modèle de conception qui isole la source de données du reste d’une application. Le référentiel assure la médiation entre les sources de données (telles que les services Web et les modèles persistants) et le reste d’une application.

Voici la représentation graphique de l’utilisation du modèle de référentiel.

Vous comprenez bien que le référentiel est similaire au Data Access Object (DAO) mais une abstraction qui cache toute la logique utilisée pour récupérer les données de la logique métier.

Il se comporte comme un wrapper autour du modèle et est responsable de l’accès aux données à partir d’un magasin persistant. L’avantage d’utiliser un référentiel est qu’il sépare les détails précis de la façon dont nos données seront stockées de l’application qui les utilise.

Ceci est extrêmement important pour les tests car nous pouvons écrire du code stub qui renverra toujours un User mais n’accède pas à la base de données. Cela nous libère de divers problèmes et nous permet d’écrire le test unitaire rapide de notre code d’application, qui ne dépendra pas des données stockées.

Différence entre l’objet d’accès aux données (DAO) et les modèles de référentiel en Java

La principale différence est que le référentiel ne renvoie que les objets compréhensibles par une couche appelante. Généralement, le référentiel est utilisé par une couche métier et, par conséquent, il génère les objets métier.

De l’autre côté, l’objet d’accès aux données renvoie les données qui pourraient/pourraient ne pas être l’objet métier entier. Cela signifie que les données ne sont pas un concept commercial valide.

Si nos objets métier sont uniquement les structures de données, cela peut indiquer que nous avons le problème de modélisation. Cela signifie une mauvaise conception alors qu’un référentiel aura plus de sens avec au moins des objets encapsulés correctement.

Si nous ne chargeons ou ne sauvegardons que les structures de données, alors très probablement, nous n’avons pas besoin d’un référentiel. Le Object Relational Mapping (ORM) est suffisant.

Un modèle de référentiel est la meilleure solution si nous devons traiter un objet métier composé de divers autres objets (un agrégat), et cet objet spécifique nécessite que toutes ses parties soient cohérentes (racine d’agrégat).

C’est parce qu’il résume les informations complètes de persistance. Notre application ne demande qu’un Product et le référentiel le renvoie dans son ensemble ; peu importe le nombre de requêtes/tables nécessaires pour restaurer un objet.

N’oubliez pas que l’objet métier n’est pas une entité ORM (Object Relational Mapping). C’est peut-être d’un point de vue technique, mais compte tenu de la conception, l’un modélise les éléments commerciaux et l’autre modélise les éléments de persistance.

La plupart du temps, il n’y a pas de compatibilité directe.

Voici quelques situations où nous préférons utiliser un Repository Pattern :

• Il est utilisé dans un système où nous avons de nombreuses requêtes lourdes.
• Nous utilisons des modèles de référentiel pour éviter les requêtes en double.
• Il est utilisé entre le stockage de données et les domaines (entité).
• Il est également utilisé pour rechercher et supprimer un élément en utilisant la spécification de l’entité pour laquelle le référentiel est créé.

Maintenant, comprenons cette différence via l’implémentation du code.

Différence entre la mise en œuvre des modèles DAO et de référentiel

Commençons par l’implémentation du modèle d’objet d’accès aux données.

Implémentation du modèle d’objet d’accès aux données

Ici, nous avons besoin d’avoir trois classes qui sont listées ci-dessous:

1. Une classe de domaine Employee de base
2. L’interface EmployeeDAO qui fournit des opérations CRUD faciles pour un domaine Employee
3. Une classe EmployeeDAOImplementation qui implémente l’interface EmployeeDAO

Exemple de code (classe Employee) :

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

  // write your getters/setters
}

Exemple de code (Interface EmployeeDAO) :

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

Exemple de code (Classe 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
}

Nous utilisons JPA EntityManager Interface pour communiquer avec le stockage sous-jacent. Indiquez également le mécanisme d’accès aux données pour le domaine Employee.

Implémentation du modèle de référentiel

Ce modèle encapsule le stockage, le comportement de recherche et la récupération, simulant la collection d’objets. Comme DAO, il masque également les requêtes et traite les données, mais se situe à un niveau supérieur plus proche de la logique métier de l’application.

Un référentiel peut également utiliser le DAO pour récupérer les données d’une base de données. En outre, il peut remplir l’objet de domaine ou préparer des données à partir du domaine, puis les envoyer au système de stockage à l’aide de DAO pour la persistance.

Ici, nous avons besoin des classes suivantes :

1. Une interface EmployeeRepository
2. Une classe EmployeeRepositoryImplementation

Exemple de code (Interface EmployeeRepository) :

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

Exemple de code (Classe 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
}

Ici, nous utilisons la EmployeeDAOImplementation pour récupérer/envoyer des données d’une base de données. Nous pouvons donc dire que l’implémentation du référentiel et de DAO se ressemble.

C’est parce que la classe Employee est le domaine anémique et qu’un référentiel n’est qu’une autre couche au-dessus de la couche d’accès aux données (DAO) ; cependant, un référentiel est le meilleur moyen de mettre en œuvre le cas d’utilisation métier. En comparaison, l’objet d’accès aux données semble être un bon candidat pour accéder aux données.