Discussion :

[hed62]

Bonjour tout le monde !

J'ai un problème à résoudre, avis aux grands chefs

Je dispose (cadre d'une architecture type MVC) d'un Model.

A l'arrivée sur une Vue le Model est considéré comme 'neuf' (inchangé donc)

La Vue/Controller effectue des opérations qui viennent modifier (ou pas) le Model.

Lors d'une opération spécifique (validation et passage à l'écran suivant), je dois détecter
1/ si le Model a changé
2/ et si oui quelles propriétés de quels objets ont changé.

J'ai bien pensé à utiliser une hashtable afin de stocker les noms des propriétés qui ont changé, mais cela implique une refonte de pas mal de choses (le nombre d'objets est considérable) , de passer des clefs à ralonge (pour différencier toutes les propriétés et de où elles viennent). C'est une solution qui ne me plait guère, auriez vous des suggestions ?

[bruno_pages]

incroyable, c'est bien la première fois que je te vois poser une question et non répondre aux demandes des autres

si le type de tous les objets modifiables héritent d'une (nouvelle) interface Historized et que tu repères chaque propriété modifiable par son nom tu peux avoir

• soit une hashtable dont la clef est une instance d'Historized et la valeur la liste des noms de propriétés modifiée. Dans ce cas lorsqu'une propriété est modifié soit tu ajoutes un nouveau couple dans la hashtable soit tu complètes la liste des propriétés modifiée sur l'objet
• soit tu gardes au sein de chaque Historized la liste des propriétés modifiées. La mise à jour est alors plus rapide (pas de recherche préalable dans une hashtable), mais Historized n'est plus une vrai interface ce qui peut poser des problèmes d'héritage multiple si c'est comme je le pense du C#. Ensuite il faut balayer la liste de toutes les instances de Historized et voir ce qui est modifie

le choix entre les deux dépend donc du rapport nombre d'instances modifiable / nombre d'instances modifiées

[hed62]

soit une hashtable dont la clef est une instance d'Historized et la valeur la liste des noms de propriétés modifiée.

Bonne idee, je n'y avais pas songé (pour moi la valeur était plutôt inutilisée)
Mais si je manipule une grappe d'Historized qui s'agrègent tous les uns les autres (sans cycle) , comment je fais pour différencier qui est modifié ? en parcourant la HashTable et en comparant (par adresse pointeur) la clef et l'objet que j'inspecte ?

Je veux dire, j'ai dans mon modèle une liste de client qui ont chacun une liste de produit commandés (le nombre de niveaux peut aller bien plus loin..) en parcourant la HashTable pour savoir qui a changé, je vais récupérer des références sur des objets, sans trop savoir d'où ils viennent (plutôt je ne connaitrait pas leur parent, ce genre de choses)... enfin je crois.. il faut que je me penche là dessus.

---------------

d'héritage multiple

Effectivement mes objet héritent déjà, mais ce n'est pas très grave, je peut toujours faire de la délégation au besoin, ou utiliser le type de la classe mère comme point commun...

soit ... la liste des propriétés modifiées

Mais du coup, là encore, comment différencier la propriété 'Nom' du troisième Client et la propriété 'Nom' du 1er Produit commandé ?


------

J'avais envisagé un Observer/observed pour ce problème, mais la mise en place est lourde, le rework important...


Merci de m'aider

[bruno_pages]

comment je fais pour différencier qui est modifié ? en parcourant la HashTable et en comparant (par adresse pointeur) la clef et l'objet que j'inspecte ?

non, la clef donne l'objet lui même puis que la clef EST l'objet

ensuite, suivant ce que tu veux faire avec il te faudra sans doute ajouter des opérations abstraites sur l'interface implémentées par les vraies classes afin de faire le boulot demander

en parcourant la HashTable pour savoir qui a changé, je vais récupérer des références sur des objets, sans trop savoir d'où ils viennent (plutôt je ne connaitrait pas leur parent, ce genre de choses)

j'ai supposé que ces objets connaissaient déjà deux trois trucs sur eux même, il te faudra donc l'ajouter si besoin

Mais du coup, là encore, comment différencier la propriété 'Nom' du troisième Client et la propriété 'Nom' du 1er Produit commandé ?

chaque classe se connait (d'une façon ou d'une autre) et donc chaque instance sait a quoi correspond tel ou tel nom (ou numéro) de propriété ... ya pas de magie

J'avais envisagé un Observer/observed pour ce problème, mais la mise en place est lourde, le rework important...

un observer est en effet lourd pour juste mémoriser les changements

mais de toute façon tu auras un rework, chaque setter ou equivalent devra mettre la hashtable a jour, meme si cela se fait via une opération definie une fois pour toute sur Historized

[edit]je ne sais pas si C# a un équivalent au macros de C/C++, cela pourrait alléger l'introduction du code gérant tout cette mécanique[/edit]

[hed62]

non, la clef donne l'objet lui même puis que la clef EST l'objet

of course

il te faudra donc l'ajouter si besoin

Ok, je voulais bien être sur de ça. Reste à voir si ca rentre dans tout le bazar que j'ai dans le projet.

ya pas de magie

Ma question concernait la proposition n°2. En fait, il me faut un identifiant de propriété unique, pour chaque propriété. Inenvisageable j'en ai peur, trop de propriété, trop d'objets.

chaque setter ou equivalent devra mettre la hashtable a jour

95% des objets dont je parle sont générés, il y a donc moyen de faire cela relativement vite.


Je pense partir sur la solution 1.
Merci pour ton aide

Je vais laisser un jour ou deux, puis je mettrais en résolu.