Tutorial 11 – Sauvegarde des Données

La vidéo du tutorial

Commande de sauvegarde

Nous allons ajouter un bouton qui va nous permettre de sauvegarder nos données dans la Base.

Dans Visual Studio, ajoutons un Bouton dans le Control Toolbar. Nommons le BtnSave, avec la value Save. Compilons la solution.	<div aas:control="ToolBar"> <input name="BtnSave" type="button" value="Save" /> </div>
Dans BindingStudio, ajoutons une nouvelle vue sur le contrôle Toolbar. Un nouveau Binding apparait pour le bouton BtnSave. L’évènement click est disponible pour Binder une Commande. Jusqu’à présent, tous nos Binding de Commande pointaient vers des Commandes Serveur que nous avions écrit dans notre code, et qui concernaient le chargement des données. Il se trouve que la Commande de sauvegarde de données est complètement générique et déjà disponible dans le serveur.
Dans la liste des Commandes, nous voyons le service DataAccessAdventureWorks. C’est le service que nous avons configuré avec la ConnectionString de la base de données. Ce service a des commandes bindable, et notamment la commande SaveTransactional. Cette commande a 2 paramètres, dataSet et updateConcurrencyStrategy.
Bindons le 1er paramètre sur notre DataSet ADWData. Le 2ème paramètre est la gestion de la Concurrence, qui peut prendre les valeurs suivantes: - 0: la concurrence est testée sur toutes les colonnes, c’est le lock optimiste classique. - 1: la concurrence est testée sur les colonnes modifiées uniquement.  - 2: la concurrence n’est pas testée, c’est le dernier qui sauve qui a raison. Nous allons supprimer le 2ème paramètre, ce qui revient à prendre sa valeur par défaut, qui est le lock optimiste sur toutes les colonnes.
Sur la vue ADWMain, ajoutons un Layout pour la vue ToolBar. Le layout est dans la zone ZoneToolbar, et la vue est affichée par défaut. Sauvegardons notre configuration.

En relançant l’Application, nous constatons que la Vue Toolbar s’affiche bien à l’endroit souhaité (nous avions fait le css dans ce but), avec le bouton Save.

Si nous modifions un nom de Produit, et que l’on click sur le bouton Save, on constatera que la valeur est bien mise à jour dans la base.

Il faut comprendre le mécanisme d’échange qui est fait ici:

• Lorsque l’on modifie le nom de Produit, le Binding marque la ligne concernée comme modifiée.
• Dans le client, à l’appel de la commande Save, le DataSet passé en paramètre est analysé.
• Toutes les lignes modifiées, ajoutées ou supprimées sont extraites du DataSet.
• Seules ces lignes altérées sont envoyées au Serveur. S’il n’y a aucun ligne concernée, la Commande n’est pas appelée.
• Le Serveur reçoit toutes les lignes altérées. A l’aide du Schéma, les Commandes de sauvegarde sont exécutées dans la base. Le lock optimist est pris en compte.
• Au retour de la commande, et s’il n’y a pas eu d’erreur, les lignes altérées sont passées en Unchanged, de façon à ne plus être prise en compte lors de la prochaine sauvegarde.

Ainsi, l’aller et retour avec le serveur n’est fait que s’il y a réellement des données à sauvegarder, et le volume des données échangées est réduit aux données nécessaires à la sauvegarde.

Voilà, nous avons géré la sauvegarde sans écrire la moindre ligne de code. Quel que soit la complexité du schéma, la sauvegarde est automatique. Nous verrons qu’elle peut être complètement transparente dans la navigation dans notre application, en étant bindée à différents endroits.

La suite, au prochain épisode.