Partager via

Implémentation de l’accès concurrentiel optimiste (C#)

  • Article

par Scott Mitchell

Télécharger le PDF

Pour une application web qui permet à plusieurs utilisateurs de modifier des données, il existe le risque que deux utilisateurs modifient les mêmes données en même temps. Dans ce tutoriel, nous allons implémenter un contrôle d’accès concurrentiel optimiste pour gérer ce risque.

Introduction

Pour les applications web qui autorisent uniquement les utilisateurs à afficher des données, ou pour celles qui n’incluent qu’un seul utilisateur pouvant modifier des données, il n’existe aucune menace que deux utilisateurs simultanés écrasent accidentellement les modifications de l’autre. Toutefois, pour les applications web qui permettent à plusieurs utilisateurs de mettre à jour ou de supprimer des données, il est possible que les modifications d’un utilisateur entrent en conflit avec celles d’un autre utilisateur simultané. Sans stratégie d’accès concurrentiel en place, lorsque deux utilisateurs modifient simultanément un seul enregistrement, l’utilisateur qui valide ses modifications en dernier remplace les modifications apportées par le premier.

Par exemple, imaginez que deux utilisateurs, Jisun et Sam, visitaient une page de notre application qui permettait aux visiteurs de mettre à jour et de supprimer les produits via un contrôle GridView. Tous les deux cliquez sur le bouton Modifier dans GridView en même temps. Jisun remplace le nom du produit par « Chai Tea » et clique sur le bouton Mettre à jour. Le résultat net est une UPDATE instruction envoyée à la base de données, qui définit tous les champs pouvant être mis à jour du produit (même si Jisun n’a mis à jour qu’un seul champ, ProductName). À ce stade, la base de données a les valeurs « Thé Chai », la catégorie Boissons, le fournisseur Liquides exotiques, et ainsi de suite pour ce produit particulier. Toutefois, l’écran GridView sur Sam affiche toujours le nom du produit dans la ligne GridView modifiable sous la forme « Chai ». Quelques secondes après la validation des modifications de Jisun, Sam met à jour la catégorie sur Condiments et clique sur Mettre à jour. Il en résulte une UPDATE instruction envoyée à la base de données qui définit le nom du produit sur « Chai », sur CategoryID l’ID de catégorie Boissons correspondant, etc. Les modifications apportées par Jisun au nom du produit ont été remplacées. La figure 1 représente graphiquement cette série d’événements.

Lorsque deux utilisateurs mettent simultanément à jour un enregistrement, il est possible qu’un utilisateur change pour remplacer l’autre

Figure 1 : Lorsque deux utilisateurs mettent simultanément à jour un enregistrement, il est possible qu’un utilisateur change pour remplacer les autres (cliquez pour afficher l’image en taille réelle)

De même, lorsque deux utilisateurs visitent une page, un utilisateur peut être en train de mettre à jour un enregistrement lorsqu’il est supprimé par un autre utilisateur. Ou, entre le moment où un utilisateur charge une page et qu’il clique sur le bouton Supprimer, un autre utilisateur peut avoir modifié le contenu de cet enregistrement.

Trois stratégies de contrôle d’accès concurrentiel sont disponibles :

  • Ne rien faire : si des utilisateurs simultanés modifient le même enregistrement, laissez la dernière validation gagner (comportement par défaut)
  • Accès concurrentiel optimiste : supposons que même s’il peut y avoir des conflits d’accès concurrentiel de temps en temps, la grande majorité du temps de tels conflits ne se produisent pas ; par conséquent, si un conflit survient, il suffit d’informer l’utilisateur que ses modifications ne peuvent pas être enregistrées, car un autre utilisateur a modifié les mêmes données
  • Accès concurrentiel pessimiste : supposons que les conflits d’accès concurrentiel sont courants et que les utilisateurs ne tolèrent pas qu’on leur indique que leurs modifications n’ont pas été enregistrées en raison de l’activité simultanée d’un autre utilisateur ; par conséquent, lorsqu’un utilisateur commence à mettre à jour un enregistrement, verrouillez-le, empêchant ainsi d’autres utilisateurs de modifier ou de supprimer cet enregistrement jusqu’à ce que l’utilisateur valide leurs modifications

Jusqu’à présent, tous nos tutoriels ont utilisé la stratégie de résolution d’accès concurrentiel par défaut, à savoir, nous avons laissé la dernière écriture gagner. Dans ce tutoriel, nous allons examiner comment implémenter un contrôle d’accès concurrentiel optimiste.

Notes

Nous n’examinerons pas d’exemples de concurrence pessimistes dans cette série de tutoriels. L’accès concurrentiel pessimiste est rarement utilisé, car ces verrous, s’ils ne sont pas correctement abandonnés, peuvent empêcher d’autres utilisateurs de mettre à jour des données. Par exemple, si un utilisateur verrouille un enregistrement pour modification, puis part pour la journée avant son déverrouillage, aucun autre utilisateur ne pourra mettre à jour cet enregistrement tant que l’utilisateur d’origine n’aura pas retourné et terminé sa mise à jour. Par conséquent, dans les situations où l’accès concurrentiel pessimiste est utilisé, il existe généralement un délai d’expiration qui, s’il est atteint, annule le verrou. Les sites web de vente de billets, qui verrouillent un emplacement particulier pendant une courte période pendant que l’utilisateur termine le processus de commande, sont un exemple de contrôle d’accès concurrentiel pessimiste.

Étape 1 : Examiner comment l’accès concurrentiel optimiste est implémenté

Le contrôle d’accès concurrentiel optimiste fonctionne en s’assurant que l’enregistrement en cours de mise à jour ou de suppression a les mêmes valeurs que lors du démarrage du processus de mise à jour ou de suppression. Par exemple, lorsque vous cliquez sur le bouton Modifier dans un GridView modifiable, les valeurs de l’enregistrement sont lues à partir de la base de données et affichées dans TextBoxes et d’autres contrôles Web. Ces valeurs d’origine sont enregistrées par GridView. Plus tard, une fois que l’utilisateur a apporté ses modifications et cliqué sur le bouton Mettre à jour, les valeurs d’origine plus les nouvelles valeurs sont envoyées à la couche de logique métier, puis à la couche d’accès aux données. La couche d’accès aux données doit émettre une instruction SQL qui met à jour l’enregistrement uniquement si les valeurs d’origine que l’utilisateur a commencé à modifier sont identiques aux valeurs toujours dans la base de données. La figure 2 illustre cette séquence d’événements.

Pour que la mise à jour ou la suppression réussisse, les valeurs d’origine doivent être égales aux valeurs de base de données actuelles

Figure 2 : Pour que la mise à jour ou la suppression réussisse, les valeurs d’origine doivent être égales aux valeurs de base de données actuelles (cliquer pour afficher l’image en taille réelle)

Il existe différentes approches pour implémenter l’accès concurrentiel optimiste (voir La logique de mise à jour de l’accès concurrentiel optimiste de Peter A. Bromberg pour un bref aperçu d’un certain nombre d’options). Le ADO.NET DataSet typé fournit une implémentation qui peut être configurée uniquement avec la coche d’une case à cocher. L’activation de l’accès concurrentiel optimiste pour un Objet TableAdapter dans le Jeu de données type augmente les instructions et DELETE de UPDATE TableAdapter pour inclure une comparaison de toutes les valeurs d’origine dans la WHERE clause . L’instruction suivante UPDATE , par exemple, met à jour le nom et le prix d’un produit uniquement si les valeurs de base de données actuelles sont égales aux valeurs qui ont été récupérées à l’origine lors de la mise à jour de l’enregistrement dans GridView. Les @ProductName paramètres et @UnitPrice contiennent les nouvelles valeurs entrées par l’utilisateur, tandis que @original_ProductName et @original_UnitPrice contiennent les valeurs qui ont été initialement chargées dans gridView lorsque l’utilisateur a cliqué sur le bouton Modifier :

UPDATE Products SET
    ProductName = @ProductName,
    UnitPrice = @UnitPrice
WHERE
    ProductID = @original_ProductID AND
    ProductName = @original_ProductName AND
    UnitPrice = @original_UnitPrice

Notes

Cette UPDATE instruction a été simplifiée pour des fins de lisibilité. Dans la pratique, la UnitPrice case activée dans la WHERE clause serait plus impliquée, car UnitPrice peut contenir NULL des et vérifier si NULL = NULL retourne toujours False (à la place, vous devez utiliser IS NULL).

En plus d’utiliser une autre instruction sous-jacente UPDATE , la configuration d’un TableAdapter pour utiliser l’accès concurrentiel optimiste modifie également la signature de ses méthodes directes de base de données. Rappelez-vous de notre premier tutoriel, Création d’une couche d’accès aux données, que les méthodes directes de base de données étaient celles qui acceptent une liste de valeurs scalaires comme paramètres d’entrée (plutôt qu’une instance DataRow ou DataTable fortement typée). Lors de l’utilisation de l’accès concurrentiel optimiste, les méthodes et direct Update()Delete() de la base de données incluent également des paramètres d’entrée pour les valeurs d’origine. En outre, le code dans la BLL pour l’utilisation du modèle de mise à jour par lots (les Update() surcharges de méthode qui acceptent DataRows et DataTables plutôt que les valeurs scalaires) doit également être modifié.

Au lieu d’étendre les TableAdapters de notre DAL existants pour utiliser l’accès concurrentiel optimiste (ce qui nécessiterait de modifier la BLL pour prendre en charge), créons plutôt un jeu de données typé nommé NorthwindOptimisticConcurrency, auquel nous allons ajouter un Products TableAdapter qui utilise l’accès concurrentiel optimiste. Ensuite, nous allons créer une ProductsOptimisticConcurrencyBLL classe de couche de logique métier qui a les modifications appropriées pour prendre en charge le DAL d’accès concurrentiel optimiste. Une fois ce travail de base posé, nous serons prêts à créer la page ASP.NET.

Étape 2 : Création d’une couche d’accès aux données qui prend en charge l’accès concurrentiel optimiste

Pour créer un dataset typé, cliquez avec le bouton droit sur le DAL dossier dans le App_Code dossier et ajoutez un nouveau DataSet nommé NorthwindOptimisticConcurrency. Comme nous l’avons vu dans le premier tutoriel, cela permet d’ajouter un nouveau TableAdapter au DataSet typé, en lançant automatiquement l’Assistant Configuration de TableAdapter. Dans le premier écran, nous sommes invités à spécifier la base de données à laquelle se connecter : connectez-vous à la même base de données Northwind à l’aide du NORTHWNDConnectionString paramètre de Web.config.

Se connecter à la même base de données Northwind

Figure 3 : Se connecter à la même base de données Northwind (cliquer pour afficher l’image en taille réelle)

Ensuite, nous sommes invités à savoir comment interroger les données : par le biais d’une instruction SQL ad hoc, d’une nouvelle procédure stockée ou d’une procédure stockée existante. Étant donné que nous avons utilisé des requêtes SQL ad hoc dans notre DAL d’origine, utilisez également cette option ici.

Spécifier les données à récupérer à l’aide d’une instruction SQL ad hoc

Figure 4 : Spécifier les données à récupérer à l’aide d’une instruction SQL ad hoc (cliquer pour afficher l’image en taille réelle)

Dans l’écran suivant, entrez la requête SQL à utiliser pour récupérer les informations sur le produit. Utilisons exactement la même requête SQL que celle utilisée pour l’objet Products TableAdapter à partir de notre DAL d’origine, qui retourne toutes les Product colonnes ainsi que les noms de fournisseur et de catégorie du produit :

SELECT   ProductID, ProductName, SupplierID, CategoryID, QuantityPerUnit,
           UnitPrice, UnitsInStock, UnitsOnOrder, ReorderLevel, Discontinued,
           (SELECT CategoryName FROM Categories
              WHERE Categories.CategoryID = Products.CategoryID)
              as CategoryName,
           (SELECT CompanyName FROM Suppliers
              WHERE Suppliers.SupplierID = Products.SupplierID)
              as SupplierName
FROM     Products

Utiliser la même requête SQL à partir de Products TableAdapter dans le DAL d’origine

Figure 5 : Utiliser la même requête SQL à partir de Products TableAdapter dans le DAL d’origine (cliquez pour afficher l’image en taille réelle)

Avant de passer à l’écran suivant, cliquez sur le bouton Options avancées. Pour que ce TableAdapter utilise le contrôle d’accès concurrentiel optimiste, case activée simplement la case à cocher « Utiliser l’accès concurrentiel optimiste ».

Activer le contrôle d’accès concurrentiel optimiste en vérifiant la case à cocher « Utiliser l’accès concurrentiel optimiste »

Figure 6 : Activer le contrôle d’accès concurrentiel optimiste en vérifiant la case à cocher « Utiliser l’accès concurrentiel optimiste » (cliquez pour afficher l’image en taille réelle)

Enfin, indiquez que TableAdapter doit utiliser les modèles d’accès aux données qui remplissent un DataTable et retournent un DataTable ; indiquent également que les méthodes directes de base de données doivent être créées. Modifiez le nom de la méthode pour le modèle Return a DataTable de GetData en GetProducts, afin de miroir les conventions d’affectation de noms que nous avons utilisées dans notre DAL d’origine.

Faire en ce que TableAdapter utilise tous les modèles d’accès aux données

Figure 7 : Faire en ce que l’élément TableAdapter utilise tous les modèles d’accès aux données (cliquez pour afficher l’image en taille réelle)

Une fois l’Assistant terminé, l’Designer DataSet inclut un DataTable et un TableAdapter fortement typésProducts. Prenez un moment pour renommer le DataTable de Products en ProductsOptimisticConcurrency, ce que vous pouvez faire en cliquant avec le bouton droit sur la barre de titre du DataTable et en choisissant Renommer dans le menu contextuel.

Un DataTable et un TableAdapter ont été ajoutés au DataSet typé

Figure 8 : Un DataTable et Un TableAdapter ont été ajoutés au DataSet typé (Cliquez pour afficher l’image en taille réelle)

Pour voir les différences entre les UPDATE requêtes et DELETE entre tableAdapter ProductsOptimisticConcurrency (qui utilise l’accès concurrentiel optimiste) et la table Products TableAdapter (qui ne le fait pas), cliquez sur tableAdapter et accédez à la Fenêtre Propriétés. Dans les DeleteCommand sous-propriétés des CommandText propriétés et UpdateCommand , vous pouvez voir la syntaxe SQL réelle qui est envoyée à la base de données lorsque les méthodes de mise à jour ou de suppression du DAL sont appelées. Pour tableAdapter ProductsOptimisticConcurrency , l’instruction DELETE utilisée est la suivante :

DELETE FROM [Products]
    WHERE (([ProductID] = @Original_ProductID)
    AND ([ProductName] = @Original_ProductName)
    AND ((@IsNull_SupplierID = 1 AND [SupplierID] IS NULL)
       OR ([SupplierID] = @Original_SupplierID))
    AND ((@IsNull_CategoryID = 1 AND [CategoryID] IS NULL)
       OR ([CategoryID] = @Original_CategoryID))
    AND ((@IsNull_QuantityPerUnit = 1 AND [QuantityPerUnit] IS NULL)
       OR ([QuantityPerUnit] = @Original_QuantityPerUnit))
    AND ((@IsNull_UnitPrice = 1 AND [UnitPrice] IS NULL)
       OR ([UnitPrice] = @Original_UnitPrice))
    AND ((@IsNull_UnitsInStock = 1 AND [UnitsInStock] IS NULL)
       OR ([UnitsInStock] = @Original_UnitsInStock))
    AND ((@IsNull_UnitsOnOrder = 1 AND [UnitsOnOrder] IS NULL)
       OR ([UnitsOnOrder] = @Original_UnitsOnOrder))
    AND ((@IsNull_ReorderLevel = 1 AND [ReorderLevel] IS NULL)
       OR ([ReorderLevel] = @Original_ReorderLevel))
    AND ([Discontinued] = @Original_Discontinued))

Alors que l’instruction DELETE pour le Product TableAdapter dans notre DAL d’origine est beaucoup plus simple :

DELETE FROM [Products] WHERE (([ProductID] = @Original_ProductID))

Comme vous pouvez le voir, la WHERE clause de l’instruction DELETE TableAdapter qui utilise l’accès concurrentiel optimiste inclut une comparaison entre chacune des valeurs de colonne existantes de la Product table et les valeurs d’origine au moment où le GridView (ou DetailsView ou FormView) a été rempli pour la dernière fois. Étant donné que tous les champs autres que ProductID, ProductNameet Discontinued peuvent avoir NULL des valeurs, des paramètres et des vérifications supplémentaires sont inclus pour comparer correctement les NULL valeurs de la WHERE clause .

Nous n’ajouterons pas de DataTables supplémentaires au DataSet optimiste avec accès concurrentiel pour ce didacticiel, car notre page de ASP.NET fournit uniquement des informations de mise à jour et de suppression sur le produit. Toutefois, nous devons toujours ajouter la GetProductByProductID(productID) méthode à TableAdapter ProductsOptimisticConcurrency .

Pour ce faire, cliquez avec le bouton droit sur la barre de titre de TableAdapter (la zone située juste au-dessus des noms de méthode Fill et GetProducts ), puis choisissez Ajouter une requête dans le menu contextuel. L’Assistant Configuration de requête TableAdapter est alors lancé. Comme avec la configuration initiale de notre TableAdapter, choisissez de créer la méthode à l’aide GetProductByProductID(productID) d’une instruction SQL ad hoc (voir la figure 4). Étant donné que la GetProductByProductID(productID) méthode retourne des informations sur un produit particulier, indiquez que cette requête est un SELECT type de requête qui retourne des lignes.

Marquez le type de requête comme « SELECT qui retourne des lignes »

Figure 9 : Marquer le type de requête comme un «SELECT qui retourne des lignes » (cliquez pour afficher l’image en taille réelle)

Dans l’écran suivant, nous sommes invités à utiliser la requête SQL, avec la requête par défaut de TableAdapter préchargée. Augmentez la requête existante pour inclure la clause WHERE ProductID = @ProductID, comme illustré dans la figure 10.

Ajouter une clause WHERE à la requête préchargée pour retourner un enregistrement de produit spécifique

Figure 10 : Ajouter une WHERE clause à la requête préchargée pour retourner un enregistrement de produit spécifique (cliquer pour afficher une image en taille réelle)

Enfin, remplacez les noms de méthodes générées par FillByProductID et GetProductByProductID.

Renommez les méthodes FillByProductID et GetProductByProductID

Figure 11 : Renommez les méthodes en FillByProductID et GetProductByProductID (Cliquez pour afficher l’image en taille réelle)

Une fois cet Assistant terminé, TableAdapter contient désormais deux méthodes pour récupérer des données : GetProducts(), qui retourne tous les produits ; et GetProductByProductID(productID), qui retourne le produit spécifié.

Étape 3 : Création d’une couche logique métier pour le dal optimiste Concurrency-Enabled

Notre classe existante ProductsBLL contient des exemples d’utilisation des modèles directs de mise à jour par lot et de base de données. La AddProduct méthode et UpdateProduct les surcharges utilisent le modèle de mise à jour par lots, en passant un ProductRow instance à la méthode Update de TableAdapter. La DeleteProduct méthode, d’autre part, utilise le modèle direct de base de données, appelant la méthode de Delete(productID) TableAdapter.

Avec le nouveau ProductsOptimisticConcurrency TableAdapter, les méthodes directes de base de données nécessitent désormais que les valeurs d’origine soient également transmises. Par exemple, la Delete méthode attend désormais dix paramètres d’entrée : , ProductID, ProductName, SupplierID, CategoryID, QuantityPerUnitUnitPriceUnitsInStock, , UnitsOnOrder, et ReorderLevelDiscontinued. Il utilise les valeurs de ces paramètres d’entrée supplémentaires dans WHERE la clause de l’instruction DELETE envoyée à la base de données, en supprimant uniquement l’enregistrement spécifié si les valeurs actuelles de la base de données sont mappées aux valeurs d’origine.

Bien que la signature de méthode pour la méthode TableAdapter Update utilisée dans le modèle de mise à jour par lots n’ait pas changé, le code nécessaire pour enregistrer les valeurs d’origine et les nouvelles valeurs a. Par conséquent, plutôt que d’essayer d’utiliser le DAL avec accès concurrentiel optimiste avec notre classe existante ProductsBLL , créons une nouvelle classe de couche logique métier pour travailler avec notre nouvelle DAL.

Ajoutez une classe nommée ProductsOptimisticConcurrencyBLL au BLL dossier dans le App_Code dossier.

Ajouter la classe ProductsOptimisticConcurrencyBLL au dossier BLL

Figure 12 : Ajouter la ProductsOptimisticConcurrencyBLL classe au dossier BLL

Ensuite, ajoutez le code suivant à la ProductsOptimisticConcurrencyBLL classe :

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using NorthwindOptimisticConcurrencyTableAdapters;
[System.ComponentModel.DataObject]
public class ProductsOptimisticConcurrencyBLL
{
    private ProductsOptimisticConcurrencyTableAdapter _productsAdapter = null;
    protected ProductsOptimisticConcurrencyTableAdapter Adapter
    {
        get
        {
            if (_productsAdapter == null)
                _productsAdapter = new ProductsOptimisticConcurrencyTableAdapter();
            return _productsAdapter;
        }
    }
    [System.ComponentModel.DataObjectMethodAttribute
    (System.ComponentModel.DataObjectMethodType.Select, true)]
    public NorthwindOptimisticConcurrency.ProductsOptimisticConcurrencyDataTable GetProducts()
    {
        return Adapter.GetProducts();
    }
}

Notez l’instruction using NorthwindOptimisticConcurrencyTableAdapters au-dessus du début de la déclaration de classe. L’espace NorthwindOptimisticConcurrencyTableAdapters de noms contient la ProductsOptimisticConcurrencyTableAdapter classe, qui fournit les méthodes du DAL. Avant la déclaration de classe, vous trouverez également l’attribut System.ComponentModel.DataObject , qui indique à Visual Studio d’inclure cette classe dans la liste déroulante de l’Assistant ObjectDataSource.

La ProductsOptimisticConcurrencyBLLpropriété de Adapter fournit un accès rapide à un instance de la ProductsOptimisticConcurrencyTableAdapter classe et suit le modèle utilisé dans nos classes BLL d’origine (ProductsBLL, CategoriesBLL, etc.). Enfin, la GetProducts() méthode appelle simplement la méthode du GetProducts() DAL et retourne un ProductsOptimisticConcurrencyDataTable objet rempli avec un ProductsOptimisticConcurrencyRow instance pour chaque enregistrement de produit dans la base de données.

Suppression d’un produit à l’aide du modèle direct de base de données avec accès concurrentiel optimiste

Lorsque vous utilisez le modèle direct de base de données sur un DAL qui utilise la concurrence optimiste, les méthodes doivent être transmises aux valeurs nouvelles et d’origine. Pour la suppression, il n’y a pas de nouvelles valeurs. Par conséquent, seules les valeurs d’origine doivent être transmises. Dans notre BLL, nous devons donc accepter tous les paramètres d’origine comme paramètres d’entrée. La méthode de la DeleteProduct classe utilise la ProductsOptimisticConcurrencyBLL méthode directe de base de données. Cela signifie que cette méthode doit prendre les dix champs de données de produit en tant que paramètres d’entrée et les transmettre au DAL, comme indiqué dans le code suivant :

[System.ComponentModel.DataObjectMethodAttribute
(System.ComponentModel.DataObjectMethodType.Delete, true)]
public bool DeleteProduct
    (int original_productID, string original_productName,
    int? original_supplierID, int? original_categoryID,
    string original_quantityPerUnit, decimal? original_unitPrice,
    short? original_unitsInStock, short? original_unitsOnOrder,
    short? original_reorderLevel, bool original_discontinued)
{
    int rowsAffected = Adapter.Delete(original_productID,
                                      original_productName,
                                      original_supplierID,
                                      original_categoryID,
                                      original_quantityPerUnit,
                                      original_unitPrice,
                                      original_unitsInStock,
                                      original_unitsOnOrder,
                                      original_reorderLevel,
                                      original_discontinued);
    // Return true if precisely one row was deleted, otherwise false
    return rowsAffected == 1;
}

Si les valeurs d’origine (celles qui ont été chargées pour la dernière fois dans GridView (ou DetailsView ou FormView) diffèrent des valeurs de la base de données lorsque l’utilisateur clique sur le bouton Supprimer, la WHERE clause ne correspondra à aucun enregistrement de base de données et aucun enregistrement n’est affecté. Par conséquent, la méthode de Delete TableAdapter retourne 0 et la méthode de DeleteProduct BLL retourne false.

Mise à jour d’un produit à l’aide du modèle de mise à jour par lots avec accès concurrentiel optimiste

Comme indiqué précédemment, la méthode TableAdapter Update pour le modèle de mise à jour par lots a la même signature de méthode, que l’accès concurrentiel optimiste soit utilisé ou non. À savoir, la Update méthode attend un DataRow, un tableau de DataRows, un DataTable ou un DataSet typé. Il n’existe aucun paramètre d’entrée supplémentaire pour spécifier les valeurs d’origine. Cela est possible, car le DataTable effectue le suivi des valeurs d’origine et modifiées pour ses DataRow(s). Lorsque le DAL émet son UPDATE instruction, les @original_ColumnName paramètres sont remplis avec les valeurs d’origine de DataRow, tandis que les @ColumnName paramètres sont remplis avec les valeurs modifiées de DataRow.

Dans la ProductsBLL classe (qui utilise notre DAL d’accès concurrentiel non optimiste d’origine), lors de l’utilisation du modèle de mise à jour par lots pour mettre à jour les informations sur le produit, notre code effectue la séquence d’événements suivante :

  1. Lire les informations de produit de base de données actuelles dans un ProductRow instance à l’aide de GetProductByProductID(productID) la méthode TableAdapter
  2. Affecter les nouvelles valeurs au ProductRow instance de l’étape 1
  3. Appelez la méthode de Update TableAdapter, en passant le ProductRow instance

Toutefois, cette séquence d’étapes ne prend pas correctement en charge l’accès concurrentiel optimiste, car le remplissage à l’étape ProductRow 1 est rempli directement à partir de la base de données, ce qui signifie que les valeurs d’origine utilisées par DataRow sont celles qui existent actuellement dans la base de données, et non celles qui étaient liées au GridView au début du processus de modification. Au lieu de cela, lorsque vous utilisez un DAL avec accès concurrentiel optimiste, nous devons modifier les surcharges de UpdateProduct méthode pour effectuer les étapes suivantes :

  1. Lire les informations de produit de base de données actuelles dans un ProductsOptimisticConcurrencyRow instance à l’aide de GetProductByProductID(productID) la méthode TableAdapter
  2. Affecter les valeurs d’origine au ProductsOptimisticConcurrencyRow instance de l’étape 1
  3. Appelez la ProductsOptimisticConcurrencyRow méthode du AcceptChanges() instance, qui indique au DataRow que ses valeurs actuelles sont celles « d’origine »
  4. Affectez les nouvelles valeurs au ProductsOptimisticConcurrencyRow instance
  5. Appelez la méthode de Update TableAdapter, en passant le ProductsOptimisticConcurrencyRow instance

L’étape 1 lit toutes les valeurs de base de données actuelles pour l’enregistrement de produit spécifié. Cette étape est superflue dans la UpdateProduct surcharge qui met à jour toutes les colonnes de produit (car ces valeurs sont remplacées à l’étape 2), mais elle est essentielle pour ces surcharges où seul un sous-ensemble des valeurs de colonne est transmis en tant que paramètres d’entrée. Une fois les valeurs d’origine attribuées au ProductsOptimisticConcurrencyRow instance, la AcceptChanges() méthode est appelée, ce qui marque les valeurs DataRow actuelles comme valeurs d’origine à utiliser dans les @original_ColumnName paramètres de l’instructionUPDATE. Ensuite, les nouvelles valeurs de paramètre sont affectées à et ProductsOptimisticConcurrencyRow , enfin, la Update méthode est appelée, en passant le DataRow.

Le code suivant montre la UpdateProduct surcharge qui accepte tous les champs de données de produit comme paramètres d’entrée. Bien qu’elle ne soit pas affichée ici, la ProductsOptimisticConcurrencyBLL classe incluse dans le téléchargement de ce tutoriel contient également une UpdateProduct surcharge qui accepte uniquement le nom et le prix du produit comme paramètres d’entrée.

protected void AssignAllProductValues
    (NorthwindOptimisticConcurrency.ProductsOptimisticConcurrencyRow product,
    string productName, int? supplierID, int? categoryID, string quantityPerUnit,
    decimal? unitPrice, short? unitsInStock, short? unitsOnOrder,
    short? reorderLevel, bool discontinued)
{
    product.ProductName = productName;
    if (supplierID == null)
        product.SetSupplierIDNull();
    else
        product.SupplierID = supplierID.Value;
    if (categoryID == null)
        product.SetCategoryIDNull();
    else
        product.CategoryID = categoryID.Value;
    if (quantityPerUnit == null)
        product.SetQuantityPerUnitNull();
    else
        product.QuantityPerUnit = quantityPerUnit;
    if (unitPrice == null)
        product.SetUnitPriceNull();
    else
        product.UnitPrice = unitPrice.Value;
    if (unitsInStock == null)
        product.SetUnitsInStockNull();
    else
        product.UnitsInStock = unitsInStock.Value;
    if (unitsOnOrder == null)
        product.SetUnitsOnOrderNull();
    else
        product.UnitsOnOrder = unitsOnOrder.Value;
    if (reorderLevel == null)
        product.SetReorderLevelNull();
    else
        product.ReorderLevel = reorderLevel.Value;
    product.Discontinued = discontinued;
}
[System.ComponentModel.DataObjectMethodAttribute
(System.ComponentModel.DataObjectMethodType.Update, true)]
public bool UpdateProduct(
    // new parameter values
    string productName, int? supplierID, int? categoryID, string quantityPerUnit,
    decimal? unitPrice, short? unitsInStock, short? unitsOnOrder,
    short? reorderLevel, bool discontinued, int productID,
    // original parameter values
    string original_productName, int? original_supplierID, int? original_categoryID,
    string original_quantityPerUnit, decimal? original_unitPrice,
    short? original_unitsInStock, short? original_unitsOnOrder,
    short? original_reorderLevel, bool original_discontinued,
    int original_productID)
{
    // STEP 1: Read in the current database product information
    NorthwindOptimisticConcurrency.ProductsOptimisticConcurrencyDataTable products =
        Adapter.GetProductByProductID(original_productID);
    if (products.Count == 0)
        // no matching record found, return false
        return false;
    NorthwindOptimisticConcurrency.ProductsOptimisticConcurrencyRow product = products[0];
    // STEP 2: Assign the original values to the product instance
    AssignAllProductValues(product, original_productName, original_supplierID,
        original_categoryID, original_quantityPerUnit, original_unitPrice,
        original_unitsInStock, original_unitsOnOrder, original_reorderLevel,
        original_discontinued);
    // STEP 3: Accept the changes
    product.AcceptChanges();
    // STEP 4: Assign the new values to the product instance
    AssignAllProductValues(product, productName, supplierID, categoryID,
        quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel,
        discontinued);
    // STEP 5: Update the product record
    int rowsAffected = Adapter.Update(product);
    // Return true if precisely one row was updated, otherwise false
    return rowsAffected == 1;
}

Étape 4 : passage des valeurs d’origine et des nouvelles valeurs de la page ASP.NET aux méthodes BLL

Une fois le DAL et le BLL terminés, il ne reste plus qu’à créer une page ASP.NET qui peut utiliser la logique d’accès concurrentiel optimiste intégrée au système. Plus précisément, le contrôle Web de données (GridView, DetailsView ou FormView) doit mémoriser ses valeurs d’origine et ObjectDataSource doit transmettre les deux ensembles de valeurs à la couche logique métier. En outre, la page ASP.NET doit être configurée pour gérer correctement les violations d’accès concurrentiel.

Commencez par ouvrir la OptimisticConcurrency.aspx page dans le EditInsertDelete dossier et ajouter un GridView au Designer, en définissant sa ID propriété sur ProductsGrid. À partir de la balise active de GridView, choisissez de créer un ObjetDataSource nommé ProductsOptimisticConcurrencyDataSource. Étant donné que nous voulons que cet ObjetDataSource utilise le DAL qui prend en charge l’accès concurrentiel optimiste, configurez-le pour utiliser l’objet ProductsOptimisticConcurrencyBLL .

Faites en charge à ObjectDataSource d’utiliser l’objet ProductsOptimisticConcurrencyBLL

Figure 13 : Faire utiliser l’objet ProductsOptimisticConcurrencyBLL ObjectDataSource (cliquer pour afficher l’image en taille réelle)

Choisissez les GetProductsméthodes , UpdateProductet DeleteProduct dans les listes déroulantes de l’Assistant. Pour la méthode UpdateProduct, utilisez la surcharge qui accepte tous les champs de données du produit.

Configuration des propriétés du contrôle ObjectDataSource

Une fois l’Assistant terminé, le balisage déclaratif d’ObjectDataSource doit ressembler à ce qui suit :

<asp:ObjectDataSource ID="ProductsOptimisticConcurrencyDataSource" runat="server"
    DeleteMethod="DeleteProduct" OldValuesParameterFormatString="original_{0}"
    SelectMethod="GetProducts" TypeName="ProductsOptimisticConcurrencyBLL"
    UpdateMethod="UpdateProduct">
    <DeleteParameters>
        <asp:Parameter Name="original_productID" Type="Int32" />
        <asp:Parameter Name="original_productName" Type="String" />
        <asp:Parameter Name="original_supplierID" Type="Int32" />
        <asp:Parameter Name="original_categoryID" Type="Int32" />
        <asp:Parameter Name="original_quantityPerUnit" Type="String" />
        <asp:Parameter Name="original_unitPrice" Type="Decimal" />
        <asp:Parameter Name="original_unitsInStock" Type="Int16" />
        <asp:Parameter Name="original_unitsOnOrder" Type="Int16" />
        <asp:Parameter Name="original_reorderLevel" Type="Int16" />
        <asp:Parameter Name="original_discontinued" Type="Boolean" />
    </DeleteParameters>
    <UpdateParameters>
        <asp:Parameter Name="productName" Type="String" />
        <asp:Parameter Name="supplierID" Type="Int32" />
        <asp:Parameter Name="categoryID" Type="Int32" />
        <asp:Parameter Name="quantityPerUnit" Type="String" />
        <asp:Parameter Name="unitPrice" Type="Decimal" />
        <asp:Parameter Name="unitsInStock" Type="Int16" />
        <asp:Parameter Name="unitsOnOrder" Type="Int16" />
        <asp:Parameter Name="reorderLevel" Type="Int16" />
        <asp:Parameter Name="discontinued" Type="Boolean" />
        <asp:Parameter Name="productID" Type="Int32" />
        <asp:Parameter Name="original_productName" Type="String" />
        <asp:Parameter Name="original_supplierID" Type="Int32" />
        <asp:Parameter Name="original_categoryID" Type="Int32" />
        <asp:Parameter Name="original_quantityPerUnit" Type="String" />
        <asp:Parameter Name="original_unitPrice" Type="Decimal" />
        <asp:Parameter Name="original_unitsInStock" Type="Int16" />
        <asp:Parameter Name="original_unitsOnOrder" Type="Int16" />
        <asp:Parameter Name="original_reorderLevel" Type="Int16" />
        <asp:Parameter Name="original_discontinued" Type="Boolean" />
        <asp:Parameter Name="original_productID" Type="Int32" />
    </UpdateParameters>
</asp:ObjectDataSource>

Comme vous pouvez le voir, la DeleteParameters collection contient un Parameter instance pour chacun des dix paramètres d’entrée de la méthode de DeleteProduct la ProductsOptimisticConcurrencyBLL classe. De même, la UpdateParameters collection contient une Parameter instance pour chacun des paramètres d’entrée dans UpdateProduct.

Pour les tutoriels précédents qui ont impliqué la modification des données, nous allons supprimer la propriété ObjectDataSource OldValuesParameterFormatString à ce stade, car cette propriété indique que la méthode BLL s’attend à ce que les anciennes valeurs (ou d’origine) soient transmises, ainsi que les nouvelles valeurs. En outre, cette valeur de propriété indique les noms des paramètres d’entrée pour les valeurs d’origine. Étant donné que nous transmettons les valeurs d’origine dans le BLL, ne supprimez pas cette propriété.

Notes

La valeur de la OldValuesParameterFormatString propriété doit être mappé aux noms des paramètres d’entrée dans le BLL qui attendent les valeurs d’origine. Étant donné que nous avons nommé ces paramètres original_productName, original_supplierID, et ainsi de suite, vous pouvez laisser la valeur de la OldValuesParameterFormatString propriété comme original_{0}. Si, toutefois, les paramètres d’entrée des méthodes BLL avaient des noms tels que old_productName, old_supplierID, et ainsi de suite, vous devez mettre à jour la OldValuesParameterFormatString propriété vers old_{0}.

Un dernier paramètre de propriété doit être créé pour que ObjectDataSource transmette correctement les valeurs d’origine aux méthodes BLL. ObjectDataSource a une propriété ConflictDetection qui peut être affectée à l’une des deux valeurs suivantes :

  • OverwriteChanges - valeur par défaut ; n’envoie pas les valeurs d’origine aux paramètres d’entrée d’origine des méthodes BLL
  • CompareAllValues - envoie les valeurs d’origine aux méthodes BLL ; choisissez cette option lors de l’utilisation de la concurrence optimiste

Prenez un moment pour définir la ConflictDetection propriété sur CompareAllValues.

Configuration des propriétés et des champs de GridView

Une fois les propriétés d’ObjectDataSource correctement configurées, nous allons nous intéresser à la configuration de GridView. Tout d’abord, étant donné que nous voulons que GridView prend en charge la modification et la suppression, cliquez sur les cases Activer la modification et Activer la suppression à partir de la balise active de GridView. Cela ajoute un Champ de commande dont ShowEditButton et ShowDeleteButton sont tous deux définis sur true.

Lorsqu’il est lié à ProductsOptimisticConcurrencyDataSource ObjectDataSource, gridView contient un champ pour chacun des champs de données du produit. Bien qu’un tel GridView puisse être modifié, l’expérience utilisateur est tout sauf acceptable. Les CategoryID et SupplierID BoundFields s’affichent en tant que TextBoxes, ce qui oblige l’utilisateur à entrer la catégorie appropriée et le fournisseur comme numéros d’ID. Il n’y aura aucune mise en forme pour les champs numériques et aucun contrôle de validation pour s’assurer que le nom du produit a été fourni et que le prix unitaire, les unités en stock, les unités sur commande et les valeurs de niveau de réorganisation sont à la fois des valeurs numériques appropriées et sont supérieures ou égales à zéro.

Comme nous l’avons vu dans les didacticiels Ajout de contrôles de validation aux didacticiels Modification et insertion d’interfaces et Personnalisation de l’interface de modification des données , l’interface utilisateur peut être personnalisée en remplaçant BoundFields par TemplateFields. J’ai modifié ce GridView et son interface d’édition des manières suivantes :

  • Suppression des ProductIDchamps , SupplierNameet CategoryName BoundFields
  • Convertissez boundField ProductName en templateField et ajoutez un contrôle RequiredFieldValidation.
  • Convertissez et CategoryIDSupplierID BoundFields en TemplateFields, et ajustez l’interface d’édition pour utiliser DropDownLists plutôt que TextBoxes. Dans ces TemplateFields' ItemTemplates, les champs de données et SupplierName s’affichentCategoryName.
  • Convertissez les UnitPricechamps , UnitsInStock, UnitsOnOrderet ReorderLevel BoundFields en TemplateFields et ajoutez des contrôles CompareValidator.

Étant donné que nous avons déjà examiné comment accomplir ces tâches dans les tutoriels précédents, je vais simplement répertorier la syntaxe déclarative finale ici et laisser l’implémentation comme pratique.

<asp:GridView ID="ProductsGrid" runat="server" AutoGenerateColumns="False"
    DataKeyNames="ProductID" DataSourceID="ProductsOptimisticConcurrencyDataSource"
    OnRowUpdated="ProductsGrid_RowUpdated">
    <Columns>
        <asp:CommandField ShowDeleteButton="True" ShowEditButton="True" />
        <asp:TemplateField HeaderText="Product" SortExpression="ProductName">
            <EditItemTemplate>
                <asp:TextBox ID="EditProductName" runat="server"
                    Text='<%# Bind("ProductName") %>'></asp:TextBox>
                <asp:RequiredFieldValidator ID="RequiredFieldValidator1"
                    ControlToValidate="EditProductName"
                    ErrorMessage="You must enter a product name."
                    runat="server">*</asp:RequiredFieldValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label1" runat="server"
                    Text='<%# Bind("ProductName") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Category" SortExpression="CategoryName">
            <EditItemTemplate>
                <asp:DropDownList ID="EditCategoryID" runat="server"
                    DataSourceID="CategoriesDataSource" AppendDataBoundItems="true"
                    DataTextField="CategoryName" DataValueField="CategoryID"
                    SelectedValue='<%# Bind("CategoryID") %>'>
                    <asp:ListItem Value=">(None)</asp:ListItem>
                </asp:DropDownList><asp:ObjectDataSource ID="CategoriesDataSource"
                    runat="server" OldValuesParameterFormatString="original_{0}"
                    SelectMethod="GetCategories" TypeName="CategoriesBLL">
                </asp:ObjectDataSource>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label2" runat="server"
                    Text='<%# Bind("CategoryName") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Supplier" SortExpression="SupplierName">
            <EditItemTemplate>
                <asp:DropDownList ID="EditSuppliersID" runat="server"
                    DataSourceID="SuppliersDataSource" AppendDataBoundItems="true"
                    DataTextField="CompanyName" DataValueField="SupplierID"
                    SelectedValue='<%# Bind("SupplierID") %>'>
                    <asp:ListItem Value=">(None)</asp:ListItem>
                </asp:DropDownList><asp:ObjectDataSource ID="SuppliersDataSource"
                    runat="server" OldValuesParameterFormatString="original_{0}"
                    SelectMethod="GetSuppliers" TypeName="SuppliersBLL">
                </asp:ObjectDataSource>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label3" runat="server"
                    Text='<%# Bind("SupplierName") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:BoundField DataField="QuantityPerUnit" HeaderText="Qty/Unit"
            SortExpression="QuantityPerUnit" />
        <asp:TemplateField HeaderText="Price" SortExpression="UnitPrice">
            <EditItemTemplate>
                <asp:TextBox ID="EditUnitPrice" runat="server"
                    Text='<%# Bind("UnitPrice", "{0:N2}") %>' Columns="8" />
                <asp:CompareValidator ID="CompareValidator1" runat="server"
                    ControlToValidate="EditUnitPrice"
                    ErrorMessage="Unit price must be a valid currency value without the
                    currency symbol and must have a value greater than or equal to zero."
                    Operator="GreaterThanEqual" Type="Currency"
                    ValueToCompare="0">*</asp:CompareValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label4" runat="server"
                    Text='<%# Bind("UnitPrice", "{0:C}") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Units In Stock" SortExpression="UnitsInStock">
            <EditItemTemplate>
                <asp:TextBox ID="EditUnitsInStock" runat="server"
                    Text='<%# Bind("UnitsInStock") %>' Columns="6"></asp:TextBox>
                <asp:CompareValidator ID="CompareValidator2" runat="server"
                    ControlToValidate="EditUnitsInStock"
                    ErrorMessage="Units in stock must be a valid number
                        greater than or equal to zero."
                    Operator="GreaterThanEqual" Type="Integer"
                    ValueToCompare="0">*</asp:CompareValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label5" runat="server"
                    Text='<%# Bind("UnitsInStock", "{0:N0}") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Units On Order" SortExpression="UnitsOnOrder">
            <EditItemTemplate>
                <asp:TextBox ID="EditUnitsOnOrder" runat="server"
                    Text='<%# Bind("UnitsOnOrder") %>' Columns="6"></asp:TextBox>
                <asp:CompareValidator ID="CompareValidator3" runat="server"
                    ControlToValidate="EditUnitsOnOrder"
                    ErrorMessage="Units on order must be a valid numeric value
                        greater than or equal to zero."
                    Operator="GreaterThanEqual" Type="Integer"
                    ValueToCompare="0">*</asp:CompareValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label6" runat="server"
                    Text='<%# Bind("UnitsOnOrder", "{0:N0}") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Reorder Level" SortExpression="ReorderLevel">
            <EditItemTemplate>
                <asp:TextBox ID="EditReorderLevel" runat="server"
                    Text='<%# Bind("ReorderLevel") %>' Columns="6"></asp:TextBox>
                <asp:CompareValidator ID="CompareValidator4" runat="server"
                    ControlToValidate="EditReorderLevel"
                    ErrorMessage="Reorder level must be a valid numeric value
                        greater than or equal to zero."
                    Operator="GreaterThanEqual" Type="Integer"
                    ValueToCompare="0">*</asp:CompareValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label7" runat="server"
                    Text='<%# Bind("ReorderLevel", "{0:N0}") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:CheckBoxField DataField="Discontinued" HeaderText="Discontinued"
            SortExpression="Discontinued" />
    </Columns>
</asp:GridView>

Nous sommes très proches d’avoir un exemple complet. Cependant, il y a quelques subtilités qui vont se glisser et nous causer des problèmes. En outre, nous avons toujours besoin d’une interface qui alerte l’utilisateur lorsqu’une violation de concurrence s’est produite.

Notes

Pour qu’un contrôle Web de données passe correctement les valeurs d’origine à ObjectDataSource (qui sont ensuite transmises à la BLL), il est essentiel que la propriété gridView EnableViewState soit définie sur true (valeur par défaut). Si vous désactivez l’état d’affichage, les valeurs d’origine sont perdues lors de la publication.

Passage des valeurs d’origine correctes à ObjectDataSource

La façon dont GridView a été configuré pose quelques problèmes. Si la propriété de ConflictDetection ObjectDataSource est définie sur CompareAllValues (comme le nôtre), lorsque les méthodes ou Delete() de Update() ObjectDataSource sont appelées par gridView (ou DetailsView ou FormView), objectDataSource tente de copier les valeurs d’origine de GridView dans ses instances appropriéesParameter. Reportez-vous à la figure 2 pour obtenir une représentation graphique de ce processus.

Plus précisément, les valeurs d’origine de GridView se voient attribuer les valeurs dans les instructions de liaison de données bidirectionnel chaque fois que les données sont liées au GridView. Par conséquent, il est essentiel que les valeurs d’origine requises soient toutes capturées via la liaison de données bidirectionnel et qu’elles soient fournies dans un format convertible.

Pour voir pourquoi cela est important, prenez un moment pour visiter notre page dans un navigateur. Comme prévu, GridView répertorie chaque produit avec un bouton Modifier et Supprimer dans la colonne la plus à gauche.

Les produits sont répertoriés dans un GridView

Figure 14 : Les produits sont répertoriés dans un GridView (Cliquer pour afficher une image en taille réelle)

Si vous cliquez sur le bouton Supprimer pour un produit, un FormatException est levée.

La tentative de suppression d’un produit aboutit à une exception FormatException

Figure 15 : Tentative de suppression des résultats d’un produit dans un FormatException (cliquer pour afficher une image en taille réelle)

le FormatException est déclenché lorsque ObjectDataSource tente de lire dans la valeur d’origine UnitPrice . Étant donné que le ItemTemplate a mis UnitPrice en forme en tant que devise (<%# Bind("UnitPrice", "{0:C}") %>), il inclut un symbole monétaire, comme 19,95 $. Le FormatException se produit lorsque ObjectDataSource tente de convertir cette chaîne en .decimal Pour contourner ce problème, nous disposons d’un certain nombre d’options :

  • Supprimez la mise en forme monétaire de .ItemTemplate Autrement dit, au lieu d’utiliser <%# Bind("UnitPrice", "{0:C}") %>, utilisez <%# Bind("UnitPrice") %>simplement . L’inconvénient est que le prix n’est plus mis en forme.
  • Affichez le UnitPrice mis en forme en tant que devise dans , ItemTemplatemais utilisez le Eval mot clé pour ce faire. Rappelez-vous que Eval effectue la liaison de données unidirectionnel. Comme nous devons toujours fournir la UnitPrice valeur des valeurs d’origine, nous aurons toujours besoin d’une instruction de liaison de données bidirectionnel dans le ItemTemplate, mais cela peut être placé dans un contrôle Label Web dont Visible la propriété est définie sur false. Nous pourrions utiliser le balisage suivant dans ItemTemplate :
<ItemTemplate>
    <asp:Label ID="DummyUnitPrice" runat="server"
        Text='<%# Bind("UnitPrice") %>' Visible="false"></asp:Label>
    <asp:Label ID="Label4" runat="server"
        Text='<%# Eval("UnitPrice", "{0:C}") %>'></asp:Label>
</ItemTemplate>
  • Supprimez la mise en forme monétaire du , à l’aide ItemTemplate<%# Bind("UnitPrice") %>de . Dans le gestionnaire d’événements RowDataBound GridView, accédez par programmation au contrôle Label Web dans lequel la UnitPrice valeur est affichée et définissez sa Text propriété sur la version mise en forme.
  • Laissez le UnitPrice mis en forme en tant que devise. Dans le gestionnaire d’événements RowDeleting gridView, remplacez la valeur d’origine UnitPrice existante (19,95 $) par une valeur décimale réelle à l’aide Decimal.Parsede . Nous avons vu comment accomplir quelque chose de similaire dans le RowUpdating gestionnaire d’événements dans le didacticiel Gestion des exceptions BLL- et DAL-Level dans un ASP.NET Page .

Pour mon exemple, j’ai choisi d’utiliser la deuxième approche, en ajoutant un contrôle Label Web masqué dont Text la propriété est des données bidirectionnel liées à la valeur non mise en forme UnitPrice .

Après avoir résolu ce problème, essayez de cliquer à nouveau sur le bouton Supprimer pour n’importe quel produit. Cette fois, vous obtenez un lorsque ObjectDataSource tente d’appeler InvalidOperationException la méthode de UpdateProduct BLL.

ObjectDataSource ne trouve pas une méthode avec les paramètres d’entrée qu’il souhaite envoyer

Figure 16 : ObjectDataSource impossible de trouver une méthode avec les paramètres d’entrée qu’elle souhaite envoyer (cliquer pour afficher l’image en taille réelle)

En examinant le message de l’exception, il est clair que ObjectDataSource souhaite appeler une méthode BLL DeleteProduct qui inclut original_CategoryName des paramètres et original_SupplierName d’entrée. En effet, les ItemTemplate s pour et CategoryIDSupplierID TemplateFields contiennent actuellement des instructions Bind bidirectionnel avec les CategoryName champs de données et SupplierName . Au lieu de cela, nous devons inclure des Bind instructions avec les champs de CategoryID données et SupplierID . Pour ce faire, remplacez les instructions Bind existantes par Eval des instructions, puis ajoutez des contrôles Étiquette masqués dont Text les propriétés sont liées aux champs de données et SupplierID à l’aide de la CategoryID liaison de données bidirectionnel, comme indiqué ci-dessous :

<asp:TemplateField HeaderText="Category" SortExpression="CategoryName">
    <EditItemTemplate>
        ...
    </EditItemTemplate>
    <ItemTemplate>
        <asp:Label ID="DummyCategoryID" runat="server"
            Text='<%# Bind("CategoryID") %>' Visible="False"></asp:Label>
        <asp:Label ID="Label2" runat="server"
            Text='<%# Eval("CategoryName") %>'></asp:Label>
    </ItemTemplate>
</asp:TemplateField>
<asp:TemplateField HeaderText="Supplier" SortExpression="SupplierName">
    <EditItemTemplate>
        ...
    </EditItemTemplate>
    <ItemTemplate>
        <asp:Label ID="DummySupplierID" runat="server"
            Text='<%# Bind("SupplierID") %>' Visible="False"></asp:Label>
        <asp:Label ID="Label3" runat="server"
            Text='<%# Eval("SupplierName") %>'></asp:Label>
    </ItemTemplate>
</asp:TemplateField>

Grâce à ces modifications, nous sommes maintenant en mesure de supprimer et de modifier les informations sur le produit ! À l’étape 5, nous allons voir comment vérifier que des violations d’accès concurrentiel sont détectées. Mais pour l’instant, prenez quelques minutes pour essayer de mettre à jour et de supprimer quelques enregistrements afin de vous assurer que la mise à jour et la suppression pour un seul utilisateur fonctionnent comme prévu.

Étape 5 : Test de la prise en charge de l’accès concurrentiel optimiste

Pour vérifier que des violations de concurrence sont détectées (plutôt que d’entraîner un remplacement aveugle des données), nous devons ouvrir deux fenêtres de navigateur sur cette page. Dans les deux instances de navigateur, cliquez sur le bouton Modifier pour Chai. Ensuite, dans un seul des navigateurs, remplacez le nom par « Chai Tea », puis cliquez sur Mettre à jour. La mise à jour doit réussir et renvoyer gridView à son état de pré-édition, avec « Chai Tea » comme nouveau nom de produit.

Dans l’autre fenêtre de navigateur instance, toutefois, le nom de produit TextBox affiche toujours « Chai ». Dans cette deuxième fenêtre de navigateur, mettez à 25.00jour sur UnitPrice . Sans prise en charge de la concurrence optimiste, cliquer sur Mettre à jour dans le deuxième navigateur instance reviendrait au nom du produit en « Chai », remplaçant ainsi les modifications apportées par le premier instance de navigateur. Avec l’accès concurrentiel optimiste utilisé, toutefois, le fait de cliquer sur le bouton Mettre à jour dans le deuxième navigateur instance entraîne une dbConcurrencyException.

Lorsqu’une violation d’accès concurrentiel est détectée, une dbConcurrencyException est levée

Figure 17 : Lorsqu’une violation d’accès concurrentiel est détectée, une DBConcurrencyException est levée (cliquez pour afficher l’image en taille réelle)

le DBConcurrencyException n’est levée que lorsque le modèle de mise à jour par lots du DAL est utilisé. Le modèle direct de base de données ne génère pas d’exception, il indique simplement qu’aucune ligne n’a été affectée. Pour illustrer ce problème, retournez GridView des deux instances de navigateur à leur état de pré-édition. Ensuite, dans le premier instance de navigateur, cliquez sur le bouton Modifier, remplacez le nom du produit « Chai Tea » par « Chai », puis cliquez sur Mettre à jour. Dans la deuxième fenêtre de navigateur, cliquez sur le bouton Supprimer pour Chai.

En cliquant sur Supprimer, la page publie en arrière, GridView appelle la méthode ObjectDataSource et l’ObjetDataSource Delete() appelle la méthode de DeleteProduct la ProductsOptimisticConcurrencyBLL classe, en transmettant les valeurs d’origine. La valeur d’origine ProductName du deuxième instance de navigateur est « Chai Tea », qui ne correspond pas à la valeur actuelle ProductName dans la base de données. Par conséquent, l’instruction DELETE émise pour la base de données n’affecte aucune ligne, car il n’y a aucun enregistrement dans la base de données que la WHERE clause satisfait. La DeleteProduct méthode retourne false et les données d’ObjectDataSource sont renvoyées au GridView.

Du point de vue de l’utilisateur final, le fait de cliquer sur le bouton Supprimer pour Chai Tea dans la deuxième fenêtre du navigateur a fait clignoter l’écran et, à son retour, le produit est toujours là, bien qu’il soit maintenant répertorié comme « Chai » (le changement de nom de produit effectué par le premier navigateur instance). Si l’utilisateur clique à nouveau sur le bouton Supprimer, la suppression réussit, car la valeur d’origine ProductName de GridView (« Chai ») correspond maintenant à la valeur de la base de données.

Dans ces deux cas, l’expérience utilisateur est loin d’être idéale. Nous ne voulons clairement pas montrer à l’utilisateur les détails précis de l’exception lors de l’utilisation DBConcurrencyException du modèle de mise à jour par lot. Et le comportement lors de l’utilisation du modèle direct de base de données est quelque peu confus, car la commande des utilisateurs a échoué, mais il n’y avait aucune indication précise de la raison.

Pour résoudre ces deux problèmes, nous pouvons créer des contrôles Label Web sur la page qui fournissent une explication de l’échec d’une mise à jour ou d’une suppression. Pour le modèle de mise à jour par lots, nous pouvons déterminer si une DBConcurrencyException exception s’est produite ou non dans le gestionnaire d’événements post-niveau de GridView, en affichant l’étiquette d’avertissement si nécessaire. Pour la méthode directe de base de données, nous pouvons examiner la valeur de retour de la méthode BLL (c’est-à-dire true si une ligne a été affectée, false sinon) et afficher un message d’information si nécessaire.

Étape 6 : Ajout de messages d’information et affichage de ceux-ci dans le visage d’une violation d’accès concurrentiel

Lorsqu’une violation d’accès concurrentiel se produit, le comportement présenté dépend de l’utilisation du modèle direct de mise à jour par lot ou de base de données du DAL. Notre tutoriel utilise les deux modèles, le modèle de mise à jour par lots étant utilisé pour la mise à jour et le modèle direct de base de données utilisé pour la suppression. Pour commencer, ajoutons deux contrôles Label Web à notre page qui expliquent qu’une violation de concurrence s’est produite lors de la tentative de suppression ou de mise à jour de données. Définissez les propriétés et EnableViewState le Visible contrôle Label sur false; cela les masquera lors de chaque visite de page, à l’exception des visites de pages particulières où leur Visible propriété est définie truesur .

<asp:Label ID="DeleteConflictMessage" runat="server" Visible="False"
    EnableViewState="False" CssClass="Warning"
    Text="The record you attempted to delete has been modified by another user
           since you last visited this page. Your delete was cancelled to allow
           you to review the other user's changes and determine if you want to
           continue deleting this record." />
<asp:Label ID="UpdateConflictMessage" runat="server" Visible="False"
    EnableViewState="False" CssClass="Warning"
    Text="The record you attempted to update has been modified by another user
           since you started the update process. Your changes have been replaced
           with the current values. Please review the existing values and make
           any needed changes." />

En plus de définir leurs Visiblepropriétés , EnabledViewStateet Text , j’ai également défini la CssClass propriété sur Warning, ce qui entraîne l’affichage de l’étiquette dans une police en gras large, rouge, italique et gras. Cette classe CSS Warning a été définie et ajoutée à Styles.css dans le didacticiel Examen des événements associés à l’insertion, à la mise à jour et à la suppression .

Après avoir ajouté ces étiquettes, les Designer dans Visual Studio doivent ressembler à la figure 18.

Deux contrôles d’étiquette ont été ajoutés à la page

Figure 18 : Deux contrôles d’étiquette ont été ajoutés à la page (cliquez pour afficher l’image en taille réelle)

Une fois ces contrôles Label Web en place, nous sommes prêts à examiner comment déterminer quand une violation d’accès concurrentiel s’est Visible produite, auquel moment la propriété Label appropriée peut être définie sur true, en affichant le message d’information.

Gestion des violations de concurrence lors de la mise à jour

Examinons d’abord comment gérer les violations de concurrence lors de l’utilisation du modèle de mise à jour par lots. Étant donné que de telles violations avec le modèle de mise à jour par lots entraînent la levée d’une DBConcurrencyException exception, nous devons ajouter du code à notre page ASP.NET pour déterminer si une DBConcurrencyException exception s’est produite pendant le processus de mise à jour. Si c’est le cas, nous devons afficher un message à l’utilisateur expliquant que ses modifications n’ont pas été enregistrées, car un autre utilisateur a modifié les mêmes données entre le moment où il a commencé à modifier l’enregistrement et le moment où il a cliqué sur le bouton Mettre à jour.

Comme nous l’avons vu dans le didacticiel Gestion des exceptions BLL et DAL-Level dans un ASP.NET Page , de telles exceptions peuvent être détectées et supprimées dans les gestionnaires d’événements post-niveau du contrôle Web de données. Par conséquent, nous devons créer un gestionnaire d’événements pour l’événement RowUpdated GridView qui vérifie si une DBConcurrencyException exception a été levée. Ce gestionnaire d’événements reçoit une référence à toute exception qui a été levée pendant le processus de mise à jour, comme indiqué dans le code du gestionnaire d’événements ci-dessous :

protected void ProductsGrid_RowUpdated(object sender, GridViewUpdatedEventArgs e)
{
    if (e.Exception != null && e.Exception.InnerException != null)
    {
        if (e.Exception.InnerException is System.Data.DBConcurrencyException)
        {
            // Display the warning message and note that the
            // exception has been handled...
            UpdateConflictMessage.Visible = true;
            e.ExceptionHandled = true;
        }
    }
}

En cas d’exception, ce gestionnaire d’événements DBConcurrencyException affiche le UpdateConflictMessage contrôle Label et indique que l’exception a été gérée. Une fois ce code en place, lorsqu’une violation de concurrence se produit lors de la mise à jour d’un enregistrement, les modifications de l’utilisateur sont perdues, car elles auraient remplacé les modifications d’un autre utilisateur en même temps. En particulier, gridView est retourné à son état de pré-édition et lié aux données de base de données actuelles. Cela met à jour la ligne GridView avec les modifications de l’autre utilisateur, qui n’étaient pas visibles auparavant. En outre, le UpdateConflictMessage contrôle Label explique à l’utilisateur ce qui vient de se passer. Cette séquence d’événements est détaillée dans la figure 19.

Les Mises à jour d’un utilisateur sont perdus en cas de violation d’accès concurrentiel

Figure 19 : Les Mises à jour d’un utilisateur sont perdus face à une violation d’accès concurrentiel (cliquez pour afficher l’image en taille réelle)

Notes

Sinon, au lieu de retourner le GridView à l’état de pré-édition, nous pouvons laisser gridView dans son état d’édition en définissant la KeepInEditMode propriété de l’objet passé sur GridViewUpdatedEventArgs true. Toutefois, si vous utilisez cette approche, veillez à rebiner les données à GridView (en appelant sa DataBind() méthode) afin que les valeurs de l’autre utilisateur soient chargées dans l’interface d’édition. Le code disponible en téléchargement avec ce didacticiel contient ces deux lignes de code dans le RowUpdated gestionnaire d’événements commentées ; il suffit de supprimer les marques de commentaire de ces lignes de code pour que GridView reste en mode édition après une violation d’accès concurrentiel.

Réponse aux violations d’accès concurrentiel lors de la suppression

Avec le modèle direct de base de données, aucune exception n’est levée en cas de violation d’accès concurrentiel. Au lieu de cela, l’instruction de base de données n’affecte simplement aucun enregistrement, car la clause WHERE ne correspond à aucun enregistrement. Toutes les méthodes de modification de données créées dans le BLL ont été conçues de telle sorte qu’elles retournent une valeur booléenne indiquant si elles ont ou non affecté précisément un enregistrement. Par conséquent, pour déterminer si une violation d’accès concurrentiel s’est produite lors de la suppression d’un enregistrement, nous pouvons examiner la valeur de retour de la méthode BLL DeleteProduct .

La valeur de retour d’une méthode BLL peut être examinée dans les gestionnaires d’événements de post-niveau d’ObjectDataSource via la ReturnValue propriété de l’objet ObjectDataSourceStatusEventArgs passé dans le gestionnaire d’événements. Étant donné que nous voulons déterminer la valeur de retour de la DeleteProduct méthode, nous devons créer un gestionnaire d’événements pour l’événement de Deleted ObjectDataSource. La ReturnValue propriété est de type object et peut être null si une exception a été levée et que la méthode a été interrompue avant qu’elle puisse retourner une valeur. Par conséquent, nous devons d’abord nous assurer que la ReturnValue propriété n’est pas null et est une valeur booléenne. En supposant que cette case activée réussit, nous affichons le DeleteConflictMessage contrôle Label si est ReturnValuefalse. Pour ce faire, utilisez le code suivant :

protected void ProductsOptimisticConcurrencyDataSource_Deleted(
    object sender, ObjectDataSourceStatusEventArgs e)
{
    if (e.ReturnValue != null && e.ReturnValue is bool)
    {
        bool deleteReturnValue = (bool)e.ReturnValue;
        if (deleteReturnValue == false)
        {
            // No row was deleted, display the warning message
            DeleteConflictMessage.Visible = true;
        }
    }
}

En cas de violation d’accès concurrentiel, la demande de suppression de l’utilisateur est annulée. GridView est actualisé, montrant les modifications qui se sont produites pour cet enregistrement entre le moment où l’utilisateur a chargé la page et quand il a cliqué sur le bouton Supprimer. Lorsqu’une telle violation se produit, l’étiquette DeleteConflictMessage est affichée, expliquant ce qui vient de se produire (voir la figure 20).

Une suppression d’un utilisateur est annulée en cas de violation d’accès concurrentiel

Figure 20 : Une suppression d’un utilisateur est annulée dans le visage d’une violation d’accès concurrentiel (cliquez pour afficher l’image en taille réelle)

Résumé

Il existe des opportunités de violations d’accès concurrentiel dans chaque application qui permet à plusieurs utilisateurs simultanés de mettre à jour ou de supprimer des données. Si ces violations ne sont pas prises en compte, lorsque deux utilisateurs mettent simultanément à jour les mêmes données que celui qui obtient dans la dernière écriture « gagne », le remplacement des modifications de l’autre utilisateur change. Les développeurs peuvent également implémenter un contrôle d’accès concurrentiel optimiste ou pessimiste. Le contrôle d’accès concurrentiel optimiste suppose que les violations d’accès concurrentiel sont peu fréquentes et interdit simplement une commande de mise à jour ou de suppression qui constituerait une violation d’accès concurrentiel. Le contrôle d’accès concurrentiel pessimiste suppose que les violations d’accès concurrentiel sont fréquentes et que le simple rejet de la commande de mise à jour ou de suppression d’un utilisateur n’est pas acceptable. Avec le contrôle d’accès concurrentiel pessimiste, la mise à jour d’un enregistrement implique de le verrouiller, empêchant ainsi d’autres utilisateurs de modifier ou de supprimer l’enregistrement pendant qu’il est verrouillé.

Le DataSet typé dans .NET fournit des fonctionnalités permettant de prendre en charge le contrôle d’accès concurrentiel optimiste. En particulier, les UPDATE instructions et DELETE émises pour la base de données incluent toutes les colonnes de la table, garantissant ainsi que la mise à jour ou la suppression n’aura lieu que si les données actuelles de l’enregistrement correspondent aux données d’origine que l’utilisateur avait lors de leur mise à jour ou suppression. Une fois que le DAL a été configuré pour prendre en charge l’accès concurrentiel optimiste, les méthodes BLL doivent être mises à jour. En outre, la page de ASP.NET qui appelle le BLL doit être configurée de telle sorte que l’ObjectDataSource récupère les valeurs d’origine de son contrôle web de données et les transmet à la BLL.

Comme nous l’avons vu dans ce tutoriel, l’implémentation d’un contrôle d’accès concurrentiel optimiste dans une application web ASP.NET implique la mise à jour du DAL et du BLL et l’ajout de la prise en charge dans la page ASP.NET. Le fait que ce travail supplémentaire soit ou non un investissement judicieux de votre temps et de vos efforts dépend de votre application. Si vous avez rarement des utilisateurs simultanés mettant à jour des données, ou si les données qu’ils mettent à jour sont différentes les unes des autres, le contrôle d’accès concurrentiel n’est pas un problème clé. Toutefois, si plusieurs utilisateurs de votre site travaillent régulièrement avec les mêmes données, le contrôle d’accès concurrentiel peut aider à empêcher les mises à jour ou les suppressions d’un utilisateur de remplacer involontairement ceux d’un autre utilisateur.

Bonne programmation !

À propos de l’auteur

Scott Mitchell, auteur de sept livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille comme consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui se trouve à l’adresse http://ScottOnWriting.NET.

PrécédentSuivant