Discussion :

[mkaffel]

Bonjour à tous,

A l'heure actuelle:

J'ai le modèle suivant

Objet abstrait A qui implémente une interface I.

Les objets A_V1, A_V2, A_V3 héritent de A en ajoutant ou redéfinissant certaines méthodes.

Ces objets sont des objets de visualisation qui se connectent à une BDD via des DAO.

La nouveauté :

Les données concernées peuvent maintenant être archivées (cad déplacées dans des tables d'archive).

Mon problème :

Je voudrais gérer un objet de consultation pour les données archivées sans avoir à tout recoder. En effet, dans l'objet A et dans ses objets enfants A_Vx, j'ai des méthodes qui peuvent être réutilisées (celles qui n'accèdent pas à la base) et des méthodes qui doivent être redéfinies (celles qui accèdent à la base car les méthodes DAO sont différentes).

J'ai pensé au pattern Décorateur, mais je pense pas qu'il soit adapté vu que je veux modifier des comportements existants plutôt que d'en ajouter.

En fait, j'aimerais surtout éviter d'avoir qqch comme archive_A parente de archive_A_V1, de archive_A_V2 , ... car le nombre de versions va augmenter dans le futur

Je n'ai rien contre un refactoring si vous pensez que c'est ma conception de départ qui est mauvaise.

Je suis preneur de toutes les idées ou commentaires.

En vous remerciant d'avance

Cordialement

[Luckyluke34]

Bonjour,

Pour moi de 2 choses l'une :

• L'archivage est un concept métier : l'utilisateur sait qu'il manipule des données archivées, peut agir sur l'archivage, etc. Le modèle métier doit alors évoluer pour prendre en compte cela, avec probablement de nouveaux objets métier.

• L'archivage est une problématique purement technique. A ce moment là, les objets métier n'ont à mon avis pas à savoir comment ils sont persistés (archive ou non). C'est à l'intérieur de la couche DAL (donc des DAO), de manière transparente pour l'extérieur, que l'archivage doit être géré.

[mkaffel]

Merci pour beaucoup pour ta réponse.

Je pense que je me trouve dans le deuxième cas, car les données archivées sont justes disponibles en lecture.

En fait, j'essaye de trouver la solution la plus élégante pour maintenir mon code et c'est vrai que j'avais pensé à cette solution, mais je pensais que ce n'était pas la meilleure.

En effet, car si je te suis bien dans chacune des méthodes DAO je vais devoir ajouter un paramètre qui indique si je dois rechercher mes enregistrements dans la table d'archive ou non. Ce qui par conséquence va impacter mon objet A, qui fait appel à ces méthodes, ce que j'aurais voulu éviter.

Je ne voulais pas non plus mettre un if else dans chacune de mes méthodes DAO qui étaient plutôt simples pour le moment.

C'est peut être la façon dont je veux implémenter ça qui est mauvaise...

[Luckyluke34]

En effet, car si je te suis bien dans chacune des méthodes DAO je vais devoir ajouter un paramètre qui indique si je dois rechercher mes enregistrements dans la table d'archive ou non.

Pas forcément, pourquoi ne pas laisser au DAO la responsabilité de décider comme un grand où persister l'objet A en se basant sur certaines de ses données ?

On pourrait avoir l'implémentation naïve suivante (en C# / java like) :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class ADao {
 void Save(A a) {
  if (a.GetSomething() == someValue) {
   new RegularPersistenceStrategy().Persist(a);
  }
  else {
   new ArchivePersistenceStrategy().Persist(a);
  }
 }
}

Et même chose pour la stratégie de chargement des objets...

[mkaffel]

C'est une très bonne idée, mais le problème c'est que mes méthodes DAO enregistre directement un tableau clé=>valeur en base de données.

De plus ce sont des méthodes abstraites sinon j'aurais pu définir le mode de persistance à l'instanciation de l'objet Dao.

Je me vois mal revenir sur le fonctionnement de mes classes/méthodes DAO, tu as peut-être une piste pour créer une couche d'abstraction ?

Merci pour ton aide

[Luckyluke34]

Je me vois mal revenir sur le fonctionnement de mes classes/méthodes DAO, tu as peut-être une piste pour créer une couche d'abstraction ?

Mais il va bien falloir modifier quelque chose quelque part pour prendre en compte le mode de persistance alternatif

La couche de persistance supplémentaire que je propose est RegularPersistenceStrategy et ArchivePersistenceStrategy, les DAO ne peuvent pas être ignorants de cette couche puisqu'elle est un niveau pus bas. Je ne vois pas comment ne pas modifier les DAO...

A l'inverse on pourrait avoir un DAOArchive et un DAOPersistanceNormale mais ce n'ai pas la voie que j'aurais choisi puisque ça revient à déléguer la responsabilité de choisir entre archive et normal à quelqu'un d'autre... qui ? L'objet métier lui-même n'est pas une bonne idée d'après moi.

Pour respecter une séparation claire des responsabilités, on a les comportements suivants à distribuer :

• Fournir une interface transparente pour les couches du dessus avec des méthodes simples pour ajouter/supprimer/charger/sauver des objets dans un stockage persistant...
• Analyser l'objet métier et déterminer quel mode persistance choisir en fonction de ses données
• Persister/charger vers/depuis la base de données normale (avec la connexion qui va bien)
• Persister/charger vers/depuis la base de données d'archives (avec la connexion qui va bien)

C'est un jeu de Lego pour savoir dans quel objet mettre quoi, il y a plein de possibilités.

A moins de tout mettre dans la même classe mais ce n'est pas très évolutif/modulaire/testable/robuste...