Discussion :

[petitours]

Bonjour

Je teste ma première application basée sur une base de donnée (SQLite).
Tout s'articule entre des datagridview bindés à des datatables qui sont remplis à partir de tables de la bdd.
Si modification, je modifie le datagrid view, ça se répercute dans la datatable et ensuite je demande l'enregistrement en BDD.
Si ajout ou suppression, j'ajoute ou supprime directement en bdd et je recharge de suite les datatables.

Aujourd'hui je me rends compte que l'ergonomie du truc est horrible si l'utilisateur ne peut pas annuler ses modifications et je n'arrive pas à trouver comment organiser une telle annulation de la dernière frappe (Ctr-Z).
Tant que l'utilisateur n'a pas enregistré ses modifications (datatable pas enregistré en Bdd) il peut les annuler d'un bloc en rechargeant le contenu de la table. mais si on veut revenir en arrière sur un enregistrement en bdd, sur une suppression d'enregistrement ou plus finement sur les modifications control par control dans un formulaire, comment fait-on ?

Tout ce que j'imagine reviendrait à gérer X datatables (par exemple dans un List<DataTable>, autant que de niveau de retour en arrière, et donner à l'utilisateur la possibilité d'enregistrer en Bdd telle ou telle ancienne version des datatables.
Ce serait une bonne approche ? ou je suis dans l'usine à gaz qui peut être remplacé par la class .net.ClassQueJAuraisDuMeDouterQElleExiste.restoreLastModif(indexModif)

Merci par avance pour vos avis et conseils

[Prisson]

Bonjour,
je crois que tout est dans la structuration des objets de ta BDD. j'ai coutume lorsque je crée une table qui doit stocker un nbre important de données de créer une copie de cette même table mais qui elle ne stocke les données que de manière journalière. Ainsi pour chaque utilisateur à sa déconnexion, ses données sont automatiquement supprimées dans la table de copie. Je peux ainsi donnée la main aux utilisateurs (en fonction du profil) sur leurs données stockées dans la table de copie pour toute opération de suppression , de mise à jour .... et toutes ces opérations sont répercutées automatiquement dans la table principale.

Bon si je vais dans le sens de ta préoccupation alors je m'en réjouis sinon je suis vraiment dessolé pour la distraction que je t'aurai causé.

[François DORIN]

Bonjour,

Mettre en place une politique d'annulation (Undo) est quelque chose de courante, et il existe deux patrons de conception très utilisé pour cela :

• Le patron memento : le principe est de sauvegarder l'état de tes objets à un instant donnée ;
• Le patron command : au lieu de stocker l'état de tes objets, tu stockes les transformations appliquées à ces objets ;

Patron memento
Tu stockes sur une pile l'ensemble des états que tu souhaites sauvegarder. L'état courant est tout simplement désigné par le sommet de la pile. Pour annuler la dernière opération, il suffit de dépiler un élément de la pile.

Si ce patron est assez simple de conception, il peut être très vite consommateur de ressource.

Patron commande
Le principe de base est de stocker la liste des commandes qui ont mené le système a être dans son état actuel. Il existe deux variantes en fonction de l'approche choisi :

• Compensation : l'idée est de définir pour chaque commande la commande inverse. Ainsi, en cas d'annulation, il suffit d'exécuter cette commande inverse pour revenir à l'état précédent.
• Replay : l'idée ici est d'avoir en plus de la liste des commandes, un état initial. Cet état, combiné avec la liste des commandes, permet de "rejouer" (d'où le replay) les commandes jusqu'à l'endroit désiré. Ainsi, tu te retrouves avec un système dans l'état que tu souhaites.

Chaque variante à ses avantages/inconvénients. En terme d'efficacité pure, la variante par compensation est la meilleure. Mais il n'est pas toujours facile, voire possible, d'avoir une opération inverse.
La variante Replay peut se faire à chaque fois. Mais s'il y a beaucoup d'opération, l'annulation de la dernière opération nécessite de repartir de l'état initial et de rejouer les différentes commandes. Cela peut prendre du temps.


Dans ton cas, dans la mesure où tu utilises des bases SQLite, et si elles ne sont pas trop grosses, tu peux très bien garder des copies de ta base (sous forme de fichier temporaire par exemple). Ainsi, si tu dois revenir en arrière, il te suffit de recharger la base de l'instant t-1 (ou t-2, t-3, etc... en fonction du nombre d'annulation).

Pour approfondir le sujet, j'ai trouvé ce tutoriel : http://zenika.developpez.com/tutorie...terns-command/ C'est en java, mais le principe est là

[petitours]

Merci pour vos réponses et en particulier à Dorinf pour cette réponse magistrale.

Mes données sont trés peu volumineuses, ce sont des configurations de boitiers électronique. L'annulation est importante parce que l'on a vite fait de embrouiller entre 2 cartes mais les données sont très modestes. Je vais donc partir sur le patron memento (et je suis super fier d'avoir imaginé un truc qui s'en approchait :-P)

Mais je suis aussi ravis de voir le patron commande car j'ai une autre appli qui analyse des Go de fichiers Csv qui va avoir besoin de la même chose et comme tous les traitements se font à partir d'un CSV initial que je souhaite ne pas toucher le patron mémento replay sera parfait ! C'est d’ailleurs déjà quasi en place puisque j'ai comme une sorte de script que j'enregistre pour refaire plus tard la même analyse ; mais quand on peut donner un nom au truc c'est encore mieux !

Merci