Discussion :

[phplive]

Bsr

Voilà je gère des objets persistants en relation avec une base de données

J'ai la structure suivante

Code :

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

1
2
3
4
5
6
7
8
9
10
TOPFBusinessObject
  |
  +-- TOPFPersistentObject
        |
        +-- TOPFAttributeList
              |
              +-- [0] TOPFAttribute
              +-- [1] TOPFAttribute
              +-- ...
              +-- [n] TOPFAttribute

Bref rien que du très classique...
Un même TOPFPersistentObject peut être utilisé par N TOPFBusinessObject.

Maintenant lorsque je modifie le TOPFBusinessObject donc en fait au final des TOPFAttribute je peux soit créer un memento pour chaque Attribut avec possibilité d'un undo/redo soit cloner l'attribut.
Une autre possibilité pourrait être de cloner carrément le TOPFPersistentObject et le rattacher uniquement au TOPFBusinessObject qui est à l'origine de la modification ou là encore d'utiliser le memento pattern mais ce dernier me semble lourd à mettre en place.

Au départ j'étais parti sur l'utilisation du couple newvalue/oldvalue en dur
dans chaque TOPFAttribute mais je trouve maintenant que ce n'est pas pratique. Je veux pouvoir savoir quel TOPFBusinessObject est à l'origine de quelle modification et surtout que les notifications associées aux modifications sur chaque attribut ne se propagent pas.

[chaplin]

Ca ressemble au design pattern observer, en brève lecture.

[phplive]

Bjr

Ca ressemble au design pattern observer, en brève lecture

C'est exact
Mes TOPFBusinessObject observent un TOPFPersistentObject !

Ce que je voudrais c'est éviter, lorsqu'un TOPFBusinessObject modifie un attribut, que tous les autres TOPFBusinessObject qui observent le même TOPFPersistentObject ne se mettent à jour pour rien surtout si au final l'utilisateur annule les modifications. D'où mon idée de faire en sorte que dès qu'une modification est détectée le TOPFBusinessObject pointe vers un autre TOPFPersistentObject et c'est là que je me pose la question memento pattern ou clonage

[chaplin]

l'utilisateur annule les modifications.

Tu veux mémoriser des états du coup tu veux utiliser memento ou faire du clonage pour garder en mémoire l'état précédent, c'est bien ça.

D'où mon idée de faire en sorte que dès qu'une modification est détectée le TOPFBusinessObject pointe vers un autre TOPFPersistentObject

Pourquoi un changement implique une "redirection"?

[phplive]

Tu veux mémoriser des états du coup tu veux utiliser memento ou faire du clonage pour garder en mémoire l'état précédent, c'est bien ça

Oui c'est bien ça


J'envisage un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
BusinessObject_A		PersistentObject_1 : +------------------+
  |						     |   Observateurs   | 
  +-- PersistentObject_1			     +------------------+	
						     | BusinessObject_A	|
						     | BusinessObject_B |	
BusinessObject_B                               	     | BusinessObject_C |
  | 						     +------------------+
  +-- PersistentObject_1                                      
 
 
BusinessObject_C
  |
  +-- PersistentObject_1
 
 
 
 
Modifications de BusinessObject_B par ex :
 
BusinessObject_B                                	     
  | 			
  +-- PersistentObject_1 : BusinessObject_B conserve tjrs une réf vers 
  |			   PersistentObject_1 mais ne s'en sert plus 
  |                        tant que la modification est en cours 
  |				     
  +-- PersistentObject_1a  (par copie de PersistentOject ou utilisation 
                           du memento)  
                           PersistentObject_1a conserve un lien sur
                           PersistentObject_1                                  
 
 
 
 
Application des modifications :
 
BusinessObject_B                                	     
  | 							     
  +-- PersistentObject_1  PersistentObject_1 recoit les nouvelles valeurs 
                          de PersistentObject_1a
                          puis notifie à tous ses observateurs pour leur
                          demander de se réactualiser
                          PersistentObject_1a lui est détruit ou recyclé
 
 
 
Annulation des modifications :
 
BusinessObject_B                                	     
  | 							     
  +-- PersistentObject_1  PersistentObject_1 ne change pas et ne notifie rien
                          PersistentObject_1a lui est détruit ou recyclé
                          Eventuellement BusinessObject_B réactualise tous 
                          ses objets enfants

[chaplin]

Il n'y aurait pas moyen de faire une traçabilité sur les événements, au sens où tu repère toutes les méthodes qui apportent le changement, et donc il faudrait faire des méthodes inverse au changement.

Au lien de connaître les changements au niveau de l'objet, tu cherche à connaître les opérations qui ont mené à son changement, de telle sorte que te puisses inversé les opérations et donc tu traces ces opérations.

[phplive]

Good morning

tu repère toutes les méthodes qui apportent le changement

Ca c'est facile

Si j'ai

BusinessObejct : TOPFBusinessObject;

Supposons que j'ai un attribut nommé "libelle", alors les seules méthodes qui me permettent de le modifier sont

Code :

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

BusinessObject.Libelle := 'xxxx';

ou encore

Code :

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

BusinessObject.Attributes["libelle"].asString := 'xxxx';

sachant que BusinessObject.Libelle est une propriété qui ne fait qu'accèder à l'attribut mais en le transtypant :

Code :

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

1
2
3
4
procedure TOPFBusinessObject.SetLibelle(const Value : String);
begin
  (BusinessObject.Attributes["libelle"] as IStringAttribute).Value := Value;
end;

Note que pour le moment BusinessObject.Attributes["libelle"] n'est qu'un raccourci vers
BusinessObject.PersistentObject.Attributes["libelle"].

[phplive]

Bsr

Finalement j'ai laissé de côte le memento et je clone l'objet TOPFPersistentObject lorsque je le modifie.

Nouveauté : tous mes TOPFPersistentObject sont read only par défaut lorsqu'ils ont été chargés depuis l'espace de stockage.

J'ai modifié TOPFBusinessObject ainsi et j'utilise 2 objets TOPFPersistentObject alloués uniquement lorsqu'on s'en sert.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
TOPFBusinessObject = class(...)
private
  FROPersistentObject : TOPFPersistentObject; // Objet READ ONLY
  FRWPersistentObject : TOPFPersistentObject; // Objet READ WRITE
 
protected
  function GetROPersistentObject : TOPFPersistentObject;
  procedure SetROPersistentObject(const Value : TOPFPersistentObject);
  function GetRWPersistentObject : TOPFPersistentObject;  
  procedure SetRWPersistentObject(const Value : TOPFPersistentObject);
  function GetPersistentObject : TOPFPersistentObject;  
  procedure SetPersistentObject(const Value : TOPFPersistentObject);
 
public
  property PersistentObject : TOPFPersistentObject read GetPersistentObject
    write SetPersistentObject;
 
  property ROPersistentObject : TOPFPersistentObject 
    read GetROPersistentObject
    write SetROPersistentObject;
 
  property RWPersistentObject : TOPFPersistentObject 
    read GetRWPersistentObject
    write SetRWPersistentObject;
end;

GetRWPersistentObject permet des accès en lecture écriture (ne retourne jamais nil : clone l'objet ROPersistentObject s'il existe autrement créé un nouvel objet vide)

GetROPersistentObject permet des accès en lecture seule (peut retourner nil)

GetPersistentObject permet des accès en lecture et parfois en écriture (retourne soit GetROPersistentObject soit GetRWPersistentObject mais jamais nil) : normalement il ne faut pas utiliser PersistentObject directement pour mettre à jour.

Bref je m'interdis d'écrire :
BO1.PersistentObject.Attributes["TEST"].AsString := 'modif';
ou
BO1.Attributes["TEST"].AsString := 'modif';

A la place j'utilise :
BO1.RWPersistentObject.Attributes["TEST"].AsString := 'modif';
ou
BO1.RWAttributes["TEST"].AsString := 'modif';


Pas top, mais c'est simple et efficace

Ca m'évite tout un bazard de notifications pour savoir qui veut modifier quoi.
Les attributs ignorent quel TOPFBusinessObject les modifie.

En plus mes objets RWPersistentObject étant cloné ils n'interfèrent plus avec le cache des objets TOPFPersistentObject. Le cache contient exclusivement des objets chargés depuis l'espace de stockage et bien sûr READ ONLY !

Maintenant c'est sûr que si une autre appli modifie ou supprime dans la base l'équivalent d'un objet alors qu'il est en cache ... ceci est une autre histoire