Skip to main content

LINQ to SQL - Partie 5 : Liaison de données en utilisant le contrôle ASP : LinqDataSource

Fabien Lavocat

L’article ci-dessous est la traduction de l’article de Scott Guthrie.

Par Fabien Lavocat, International Program Manager Visual Studio, formateur au laboratoire .NET à l’école supérieure d’informatique SUPINFO.

Note de l’auteur : Cet article est rédigé pour Visual Studio 2008 Bêta 2 - .NET Framework 3.5 Bêta 2. [Version RTM] Les lignes en rouge comme celles-ci, correspondent aux mises à jour pour la version RTM de Visual Studio 2008 et du .NET Framework 3.5.


Au cours des dernières semaines j'ai écrit une série d’articles sur LINQ to SQL. LINQ to SQL est un O/RM intégré (object relational mapper) qui est fourni dans le .NET Framework 3.5, et qui vous permet de modéliser facilement des bases de données relationnelles à l'aide des classes .NET. Vous pouvez utiliser des expressions LINQ pour interroger la base de données, ainsi que mettre à jour / insérer / supprimer des données.

Voici les quatre premières parties de ma série d’articles sur LINQ to SQL :

Dans les articles précédents sur LINQ to SQL, j’ai mis le focus sur comment, par programmation, utiliser LINQ to SQL pour interroger et mettre à jour facilement des données dans une base de données.

Dans mon article d’aujourd’hui, je vais couvrir le nouveau contrôle <asp:LinqDataSource> qui fait parti d’ASP.NET 3.5. Il est le nouveau contrôle de source de données pour ASP.NET (comme les contrôles ObjectDataSource et SQLDataSource présents en ASP.NET 2.0) qui permet la liaison entre les contrôles graphiques ASP.NET et le modèle de données LINQ to SQL très facilement.

Exemple d'application que nous allons développer

La simple application Web de modification de données, que je vais créer, pas à pas dans ce tutoriel permettra de manipuler/gérer les entrées d’une base de données pour des produits :

L’application prend en charge les fonctionnalités utilisateurs suivantes :

  1. Autoriser les utilisateurs à filtrer les produits par catégorie ;
  2. Autoriser les utilisateurs à trier les listes de produits en cliquant sur l’en-tête de la colonne (Nom, Prix, Quantité en stock, etc.) ;
  3. Autoriser les utilisateurs à sauter/paginer une multitude de produits (10 produits par page) ;
  4. Autoriser les utilisateurs à éditer et mettre à jour n’importe quel détail du produit sur la page ;
  5. Autoriser les utilisateurs à supprimer les produits de la liste ;

L'application Web sera mise en place avec, un modèle de données propre, et orientée objet créé à l'aide de l’ORM LINQ to SQL.

Toutes les règles d'entreprise et la logique de validation métier sont mises en œuvre dans notre couche « Données du modèle » - et non pas dans la couche d'interface utilisateur ou dans aucune des pages de l’interface utilisateur. Cela garantira :

1) Un jeu cohérent des règles d'entreprise soit utilisé partout au sein de l'application,

 2) Nous écrirons moins de code et nous ne nous répèterons moins,

3) Nous pourrons facilement modifier et adapter nos règles d'entreprise ultérieurement et non pas mettre à jour à des dizaines d’endroits différents dans notre application.

Nous allons également profiter de la prise en charge de la pagination et du tri intégré, au sein de LINQ to SQL,  pour s’assurer que les fonctionnalités, telles que la pagination de liste de produit/tri soient effectuées non pas dans la couche intermédiaire, mais plutôt dans la base de données. Ce qui signifie que seulement 10 produits sont extraits de la base de données à un moment donné- nous ne récupérons donc pas des milliers de lignes pour faire le tri et la pagination dans le serveur web. 

Qu'est-ce que le contrôle <asp:LinqDataSource> et comment peut-il aider ?

Le contrôle <asp:LinqDataSource> est un contrôle ASP.NET qui implémente le modèle du contrôle DataSource introduit avec ASP.NET 2.0. Il est similaire aux contrôles ObjectDataSource et SqlDataSource, et peut être utilisé pour lier de manière déclarative d’autres contrôles ASP.NET sur une page comme source de données. La différence est que au lieu de lier directement une base de données (comme le SqlDataSource) ou une classe générique (comme le ObjectDataSource), <asp:LinqDataSource> est créé pour lier un modèle de données LINQ.

L'un des avantages d'utiliser le contrôle <asp:LinqDataSource> est qu'il exploite la flexibilité que LINQ fondée sur les ORMs fournit. Vous n’avez pas besoin de définir des méthodes de requête, insertion, mise à jour ou suppressions personnalisées pour la source de données à appeler - au lieu de cela vous pouvez pointer le contrôle <asp:LinqDataSource> à votre modèle de données, identifier sur quel tableau d’entité vous souhaitez travailler et lier tout contrôle de l'interface utilisateur ASP.NET à <asp:LinqDataSource> et travailler avec.

Par exemple, pour obtenir une simple liste de produits sur ma page cela fonctionne avec les entités Product avec le modèle de données LINQ to SQL, je peux simplement déclarer un <asp:LinqDataSource> sur ma page qui pointe vers ma classe DataContext LINQ to SQL et identifier les entités (par exemple : produits) dans le modèle de données LINQ to SQL que je veux lier. Je peux ensuite faire pointer un GridView sur lui (par les paramètres sa propriété DataSourceID) pour obtenir une vue grille du produit contenu :

Sans avoir à faire quoi que ce soit d’autre, je peux exécuter la page et obtenir une liste de mes données Product avec le support intégré de la pagination et du tri sur les données. Je peux ajouter un bouton Modifier/Supprimer sur la grille et avoir automatiquement la prise en charge des mises à jour.  Je n'ai pas besoin d'ajouter de méthode, de mapper quelque paramètre que ce soit, ou écrire du code pour le <asp:LinqDataSource> pour gérer les requêtes et scénarios de mise à jour – il peut fonctionner avec le modèle de données LINQ to SQL que nous lui avons donné et effectuer automatiquement ces opérations. Lorsque des mises à jour sont apportées, l’ORM LINQ to SQL s’assurera automatiquement que toutes les règles métier et de logique de validation que nous avons ajouté (en tant que méthodes partielles) pour le modèle de données LINQ to SQL passent avant la persistance des données dans la base :

Important : La beauté de LINQ et LINQ to SQL est qu’il n'est évidemment pas liée à être utilisé uniquement dans les scénarios d'interface utilisateur – ou avec une liaison particulière des contrôles de l’interface utilisateur comme LinqDataSource. Comme vous l'avez vu dans mes précédents articles de cette série, écrire du code utilisant l’ORM LINQ to SQL est très propre. Vous pouvez toujours écrire du code personnalisé dans l’interface utilisateur pour travailler directement sur votre modèle de données LINQ to SQL si vous préférez, ou lorsque vous trouvez un scénario d'interface utilisateur qui n'est particulièrement pas adapté à l’utilisation de <asp:LinqDataSource>. 

Les sections ci-dessous montre, en pas à pas, comment utiliser LINQ to SQL et le contrôle de <asp:LinqDataSource> pour générer le scénario d'application web définit ci-dessus.

 

Etape 1 : Définir notre modèle de données

Nous allons commencer à travailler sur l'application en définissant en premier le modèle de données que nous allons utiliser pour représenter notre base de données. 

J'ai abordé comment créer un modèle de données LINQ to SQL en utilisant le concepteur LINQ to SQL de Visual Studio 2008 dans la Partie 2 de cette série. Voici une capture d'écran des classes du modèle de données que vous pouvez créer rapidement à l'aide lu concepteur LINQ to SQL pour modéliser la base de données exemple "Northwind" :

Nous allons réexaminer notre modèle de données à l'étape 5 de ce didacticiel, lorsque nous lui ajouterons certaines règles de validation métier. Mais pour commencer, nous allons seulement utiliser le modèle de données ci-dessus tel quel pour construire notre interface utilisateur.

 

Etape 2 : Créer une liste de produits basique

Nous allons commencer notre interface utilisateur en créant une page ASP.NET avec un contrôle <asp:GridView> sur celle-ci et utiliser quelques styles CSS :

Nous pourrions écrire du code pour lier par programmation le contrôle GridView (comme j’ai fait dans la Partie 3 de cette série) à notre modèle de données mais je pourrais également utiliser le nouveau contrôle <asp:LinqDataSource> pour lier le contrôle GridView à notre modèle de données.

Visual Studio 2008 inclut la prise en charge du concepteur intégré pour faciliter la connexion de notre GridView (ou tout autre contrôle serveur ASP.NET) à des données LINQ. Pour lier notre grille ci-dessus au modèle de données que nous avons créé précédemment, nous pouvons basculer en mode création, sélectionnez le contrôle GridView, puis l'option « Nouvelle source de données… » Dans la liste déroulante « Choisir la source de données : » :

Cela affichera une boîte de dialogue qui répertorie les options de source de données disponibles pour la créer. Sélectionnez la nouvelle option « LINQ » dans la boîte de dialogue et le nom du contrôle <asp:LinqDataSource> résultant que vous souhaitez créer :

Le concepteur du <asp:LinqDataSource> affichera ensuite les classes DataContext LINQ to SQL DataContext disponibles que votre application peut utiliser, y compris celles des bibliothèques de classes que vous référencez :

Nous voulons sélectionner le modèle données que nous avons créé plus tôt avec le concepteur LINQ to SQL. Nous voulons ensuite sélectionner la table de notre modèle de données que nous voulons définir comme entité principale pour la lier avec <asp:LinqDataSource>. Pour ce scénario nous voulons sélectionner la classe entité « Products » que nous avons construit. Nous souhaitons également sélectionner le bouton « Avancé » et activer les mises à jour et suppressions pour la source de données :

 

Lorsque nous cliquons sur le bouton « Terminer » ci-dessus, Visual Studio 2008 déclarera un <asp:LinqDataSource> dans notre page .aspx et mettra à jour le <asp:GridView> pour qu’il pointe dessus (via sa propriété DataSourceID). Il fournira également automatiquement les déclarations de colonnes dans la grille, basées sur le schéma de l'entité Product que nous avons choisit de lier :

Nous pouvons ensuite remonter le contexte de « tâche rapide » de l’interface utilisateur du contrôle GridView et indiquer que nous souhaitons lui permettre la pagination, le tri, la modification et la suppression :

Nous pouvons ensuite lancer notre application en appuyant sur F5 et nous aurons ainsi la liste des produits sur la page avec la prise en charge de la pagination et du tri (remarquez les index de pagination au bas de la grille ci-dessous) :

Nous pouvons également sélectionner le bouton « modifier » ou « supprimer » sur chaque ligne pour mettre à jour les données :

Si nous retournons sur la page en mode source, nous verrons que le balisage de la page contient le contenu ci-dessous. Le contrôle <asp:LinqDataSource> pointe vers le DataContext LINQ to SQL que nous avons créé précédemment, ainsi que vers la table entité que nous voulons lier. Le contrôle GridView pointe vers le contrôle <asp:LinqDataSource> (via son DataSourceID) et indique les colonnes qui doivent être incluses dans la grille, leur texte d'en-tête, ainsi que les expressions de tri à utiliser lorsque l'en-tête de colonne est sélectionnée.

Maintenant que nous avons les principes fondamentaux de notre travail sur l'interface utilisateur web de notre modèle de données LINQ to SQL, nous pouvons aller de l'avant et personnaliser davantage l'interface utilisateur et son comportement.

Etape 3 : Nettoyage des colonnes

Notre GridView ci-dessus a beaucoup de colonnes prédéfinies, et les valeurs de deux des colonnes (SupplierID et CategoryID) sont actuellement des numéros de clé étrangère – ce qui n’est certainement pas le moyen idéal de le présenter à un utilisateur final.

Retirer les colonnes inutiles

Nous pouvons commencer le nettoyage de notre interface utilisateur en supprimant quelques colonnes dont nous n'avons pas besoin. Je peux le faire en mode source (simplement en supprimant les déclarations <asp:boundfield>) ou en mode concepteur, juste en cliquant sur la colonne dans le concepteur : choisissez la tâche « Supprimer ». Par exemple, nous pourrions supprimer la colonne « QuantityPerUnit » ci-dessous et relancer notre application pour obtenir cette interface utilisateur légèrement plus saine :

Si vous avez déjà utilisé le contrôle <asp:ObjectDataSource> et passés explicitement les paramètres de mise à jour pour, mettre à jour les méthodes (valeur par défaut quand vous utilisez un DataSet basé sur TableAdapters) l'une des choses que vous connaissez et qui peut être douloureux c’est lorsque que vous devez modifier la signature des méthodes de mise à jour de votre TableAdapter lorsque les paramètres de votre interface utilisateur sont modifiés. Par exemple : si nous avons supprimé une colonne dans notre grille (comme ci-dessus), nous finissons par avoir à modifier notre TableAdapter pour prendre en charge les méthodes de mise à jour sans ce paramètre.

L'une des choses vraiment agréable avec le contrôle <asp:LinqDataSource> est que vous n'avez pas besoin de faire ce type de modifications. Simplement supprimer (ou ajouter) une colonne à partir de votre interface utilisateur et relancer l'application – aucune autre modification n’est nécessaire. Cela rend la modification de l'interface utilisateur Web créé à l'aide du <asp:LinqDataSource> beaucoup plus simple et permet des scénarios d’itération beaucoup plus rapides au sein d'une application.

Nettoyer les colonnes SupplierID et CategoryID

Actuellement nous affichons les valeurs des clés étrangères dans notre GridView pour les entités Supplier, Category et pour chaque Product :

Tandis que la précision dans une perspective de modèle de données, n'est pas très respectueuse de l'utilisateur. Ce que je veux vraiment faire consiste à la place, d’afficher la CategoryName et le SupplierName et fournir une liste déroulante dans le mode édition, pour permettre aux utilisateurs d'associer facilement les valeurs SupplierID et CategoryID.

Je peux modifier le contrôle GridView pour afficher le nom du fournisseur et nom de catégorie au lieu de leur code en remplaçant la valeur par défaut <asp:BoundField> dans notre GridView avec un <asp:TemplateField>. Au sein de ce TemplateField je peux ajouter tout contenu qui me permette de personnaliser l'apparence de la colonne.

Dans le code source ci-dessous je vais profiter du fait que chaque classe Product dans le modèle de données LINQ to SQL que nous avons créé possède une propriété Supplier et Category. Cela signifie que je peux facilement lier les données de leurs sous-propriétés Supplier.CompanyName et Category.CategoryName au sein de notre grille :

Et maintenant lorsque j'exécute l'application j'obtiens à la place, les noms des valeurs Category et Supplier lisibles :

Pour obtenir la liste déroulante dans l'interface utilisateur pour les colonnes Supplier et Category tandis que dans le mode édition de la grille, j'ajouterai tout d'abord deux contrôles <asp:LinqDataSource> supplémentaires sur ma page. Je les configure pour lier les catégories et les fournisseurs dans le modèle de données LINQ to SQL que nous avons créé précédemment :

Je peux ensuite revenir aux colonnes <asp:TemplateField>, que nous avons précédemment ajoutés à notre GridView et personnaliser leurs apparences (en spécifiant un EditItemTemplate). Nous allons personnaliser chaque colonne pour avoir un contrôle liste déroulante en mode édition, où les valeurs disponibles dans les listes déroulantes sont extraites des contrôles source de données ci-dessus Categories et Suppliers, et où nous lierons en bidirectionnelle la valeur sélectionnée pour les clés étrangères SupplierID et CategoryID du produit :

Et maintenant lorsque les utilisateurs finaux cliquent sur Modifier dans le contrôle GridView, elles sont présentées dans une liste déroulante de tous les fournisseurs associés avec le produit :

Et quand ils enregistrent, le produit est mis à jour (le GridView utilisera la valeur actuellement sélectionnée de l'objet DropDownList pour lier au SupplierID).

Filtrer notre liste de produits

Plutôt que montrer tous les produits de la base de données, nous pouvons mettre à jour notre interface utilisateur avec une liste déroulante qui permet à l'utilisateur de filtrer les produits pour une catégorie particulière. 

Etant donné que nous avions déjà ajouté un contrôle <asp:LinqDataSource> sur la page, qui référence nos catégories de notre modèle de données LINQ to SQL, je peux créer une liste déroulante en haut de la page qui sera liée à celui-ci. Par exemple :

Lorsque j’exécute la page je vais obtenir, en haut de la page, une liste déroulante pour filtrer toutes les catégories :

La dernière étape consiste à configurer le contrôle GridView pour afficher uniquement les produits de la catégorie que l'utilisateur final aura sélectionné à partir la liste déroulante. La façon la plus simple pour le faire, est de sélectionner l'option « configuration de la source de données » dans les tâches rapides du GridView :

Cela va me ramener à l’interface utilisateur lors du dessin du contrôle <asp:LinqDataSource> que nous avons utilisé au tout début de ce didacticiel. Je peux sélectionner le bouton « Where » pour ajouter un filtre de liaison au contrôle de source de données. Je peux ajouter n’importe quel nombre ou expression de filtrage et extraire de façon déclarative les valeurs à filtrer par une variété de choses (par exemple : de chaîne de requête, depuis valeurs du formulaire, ou d’autres contrôles sur la page, etc.) :

Ci-dessus, je vais de choisir de filtrer par les produits par leur valeur CategoryID et ensuite récupérer ce CategoryID du contrôle DropDownList, que nous avons juste créé sur notre page :

Lorsque nous aurons terminé, le contrôle <asp:LinqDataSource> de notre page aura été mis à jour avec cette clause de filtrage comme suit :

Et quand nous lançons la page de l'utilisateur final, il sera maintenant capable de pouvoir sélectionner les catégories disponibles dans la liste déroulante et de la page, et de trier, modifier et supprimer uniquement les produits de cette catégorie :

Le contrôle <asp:LinqDataSource> appliquera automatiquement l'expression de filtre LINQ appropriée lorsque vous travaillerez sur vos classes du modèle de données LINQ to SQL pour garantir que seules les données requises sont extraites de la base de données (par exemple : dans la grille ci-dessus uniquement les 3 lignes de données Product de la deuxième page de la catégorie « Confections » seront extraites de la base de données).

Vous pouvez éventuellement gérer l’événement Selecting du contrôle <asp:LinqDataSource> ou, si vous voulez, à la place, écrire une expression LINQ personnalisée dans le code pour totalement personnaliser la requête.

Etape 5 : Ajouter les règles de validation métier

Comme je l’ai indiqué dans la Partie 4 de cette série d’articles sur LINQ to SQL, lorsque nous définissons les modèles de données LINQ to SQL nous allons automatiquement avoir un jeu de schéma par défaut basé sur des contraintes de validation ajoutés à nos classes du modèle de données. Cela signifie que si j'essaye et que j’entre une valeur nulle pour une colonne requise, et que j’essaye et que j’affecte une chaîne à un entier ou que j’affecte une valeur de clé étrangère à une ligne qui n'existe pas, notre modèle de données LINQ to SQL générera une erreur et assurera le maintien de l’intégrité de la base de données.

La validation de schéma de base n'est qu'un premier pas, cependant elle est rarement suffisante pour la plupart des applications réelles. Généralement nous voudrons et aurons besoin, pour ajouter des règles de validation métier supplémentaires au niveau de l'application à nos classes du modèle de données. Heureusement, LINQ to SQL rend l’ajout de ce type de règles de validation métier facile (pour les détails sur les différentes approches de validation disponibles, veuillez lire la Partie 4 ).

Exemple de scenario de règles de validation métier

Par exemple, considérons une règle de logique métier de base que nous voulons faire respecter. Plus précisément, nous voulons nous assurer qu'un utilisateur de notre application ne peut pas interrompre un produit alors que nous avons encore des unités en stock pour lui :

Si un utilisateur essaie d'enregistrer la ligne ci-dessus, nous voulons empêcher que cette modification soit conservée et renvoie une erreur appropriée pour indiquer à l'utilisateur comment résoudre le problème.

Ajouter une règle de validation du modèle de données

Le mauvais endroit pour ajouter ce type de règle de validation métier est la couche d'interface utilisateur de notre application. L’ajouter dans la couche d'interface utilisateur de notre application signifiera que la règle soit spécifique à une place et ne seront pas automatiquement appliqués lorsque nous ajouterons une autre page à notre application qui met également à jour des produits. Distribuer des règles / logique métier dans notre couche d'interface utilisateur sera également extrêmement douloureux quand notre application grandira – puisque les modifications et mises à jour de notre entreprise nécessitera une modification de code partout.

Le bon endroit pour spécifier ce type de validation de logique métier est plutôt dans nos classes du modèle de données LINQ to SQL que nous avons définis précédemment. Comme je l’ai indiqué dans la Partie 4 de cette série, toutes les classes générées par le concepteur LINQ to SQL sont définies comme des classes « partielles » – ce qui signifie que nous pouvons facilement leurs ajouter des méthodes, des événements et des propriétés. Les classes du modèle de données LINQ to SQL appellent automatiquement les méthodes de validation que nous pouvons implémenter pour leur appliquer la logique de validation personnalisée.

Par exemple, je pourrais ajouter une classe partielle Product dans mon projet qui implémente la méthode partielle OnValidate() que LINQ to SQL appel avant de persister une entité Product. Au sein de cette méthode OnValidate() je peux ajouter la règle d'entreprise suivante, pour faire respecter que les produits ne peuvent pas avoir un Reorder Level si le produit est abandonné :

Une fois que j'ajoute la classe ci-dessus dans mon projet LINQ to SQL, la règle métier ci-dessus sera appliquée à chaque fois que quelqu'un utilise mon modèle de données pour essayer et modifier la base de données. C'est vrai pour les mises à jour de produits existants, ainsi que pour l'ajout de nouveaux produits dans la base de données.

Etant donné que le <asp:LinqDataSource> que nous avons défini dans nos pages ci-dessus fonctionne avec nos classes du modèle de données LINQ to SQL, l’ensemble de sa logique de mise à jour et d’insertion/suppression devra maintenant passer par le contrôle de validation ci-dessus avant que la modification ne soit persistée. Nous n'avons pas besoin de faire quoi que ce soit à notre couche d'interface utilisateur pour que cette validation ne se produise – elle sera automatiquement appliqué partout où notre modèle de données LINQ to SQL est utilisé.

Ajouter une belle gestion d’erreurs dans notre couche d’interface utilisateur

Par défaut si un utilisateur utilise maintenant notre GridView pour saisir une combinaison non valide d’UnitsOnOrder, nos classes du modèle de données LINQ to SQL soulèveront une exception. Le <asp:LinqDataSource> interceptera à son tour cette erreur et fournira un événement que les utilisateurs pourront utiliser pour le gérer. Ensuite, si personne ne gère l'événement, le contrôle GridView (ou autres) lié à <asp:LinqDataSource> permettra d’intercepter l'erreur et de fournir un événement géré par les utilisateurs. Si nul ne gère l'erreur, elle sera passée à la page qui la gérera et sinon ce sera le gestionnaire d'événements global Application_Error() dans le fichier Global.asax. Les développeurs peuvent choisir n'importe où dans cette voie pour insérer leur logique appropriée de gestion des erreurs pour fournir la meilleure expérience utilisateur finale.

Pour l'application que nous avons défini ci-dessus, probablement que le meilleur endroit pour gérer les erreurs de mise à jour est en gérant l'événement RowUpdated de notre GridView. Cet événement sera déclenché chaque fois qu’une mise à jour est tentée sur notre source de données, et nous pouvons accéder aux détails de l’erreur si l'événement de mise à jour échoue. Nous pouvons ajouter le code ci-dessous, pour vérifier si une erreur survient et si nous devons afficher un message d'erreur approprié à l'utilisateur final :

Notez ci-dessus la façon dont nous n’avons pas ajouté de logique de validation spécifique dans notre interface. En revanche, je récupère la chaîne du message d'erreur de validation que nous avons déclenché dans notre logique métier et je l’utilise pour afficher un message approprié à l'utilisateur final (j’affiche ensuite un message d'erreur plus générique pour d'autres défaillances).

Notez comment je j’indique également, ci-dessus, que je veux que le contrôle GridView reste en mode Edition quand une erreur se produit – c’est un moyen pour que l'utilisateur évite de perdre ses modifications et qu'il puisse modifier les valeurs qu’il a entré et cliquez sur « Mise à jour » à nouveau pour essayez de les enregistrer. Nous pouvons ensuite ajouter un contrôle <asp:literal> avec l'ID « ErrorMessage » n'importe où sur notre page pour contrôler l’endroit où nous voulons que le message d'erreur s'affiche :

Et maintenant lorsque nous essayons et mettons à jour le produit avec une combinaison de valeur non valide vous verrez un message d'erreur indiquant comment y remédier :

Ce qui est bien sur l'utilisation de cette approche est que je peux maintenant ajouter ou modifier des règles métier de mon modèle de données et ne pas avoir à modifier de code au mon niveau de l'interface utilisateur pour récupérer et appliquer les modifications. Les règles de validation et         messages d'erreurs correspondants peuvent être écrits et centralisés à un endroit dans mon modèle de données et appliquées partout automatiquement.

Résumé

Le contrôle <asp:LinqDataSource> fournit un moyen facile de lier tout contrôle ASP.NET de l’interface utilisateur à un modèle de données LINQ to SQL. Il permet aux contrôles de l'interface utilisateur de récupérer des données à partir d’un modèle de données LINQ to SQL, aussi bien que de lui appliquer proprement des mises à jour, insertions et suppressions.

Dans notre application ci-dessus nous avons utilisé le concepteur LINQ to SQL pour créer un modèle de données orientées objet propre. Puis, nous avons ajouté trois contrôles ASP.NET à notre page d’interface utilisateur (GridView, DropDownList et un littéral ErrorMessage) et ajouté trois contrôles <asp:LinqDataSource> pour les lier aux données Product, Category et Supplier : 

Nous avons ensuite écrit 5 lignes de logique de validation métier dans notre modèle de données et 11 lignes d'erreurs de logique de traitement de l'interface utilisateur.

Le résultat final est une simple application web avec l'interface utilisateur personnalisée qui permet aux utilisateurs de filtrer dynamiquement les données Product par Category, trier efficacement et paginer les résultats des produits, la modification en ligne des données Product pour enregistrer les mises à jour (en fournissant la validation de nos règles métier) et supprimer des produits du système (également en fournissant que nos règles d'entreprise l’autorise).

Dans les prochains articles dans cette série, j'aborderai plus en détail les scénarios LINQ to SQL, y compris l'accès concurrentiel optimiste, le chargement différé et hâtif, héritage de mappage de table et l'utilisation de SQL/procédures stockées personnalisées.

La semaine prochaine j’ai également planifié de démarrer une nouvelle série d’articles qui couvrent le nouveau contrôle <asp:ListView> - qui est un nouveau contrôle qui sera livré avec la version d'ASP.NET avec le .NET Framework 3.5. Il fournit le contrôle total sur les balises générées pour les scénarios de données (aucunes tables, aucun span, aucun style inline...), tout en offrant également l’intégration de scénarios d'échange, tri, édition et insertion. Par exemple, nous pourrions éventuellement l’utiliser pour remplacer l'apparence de mise en page de la grille par défaut de notre application ci-dessus par une apparence totalement personnalisée. Mieux, je pourrais le remplacer dans la page ci-dessus dans mon application et vous n’auriez même pas à modifier mon modèle de données, la déclaration du <asp:LinqDataSource> ou du code-behind de l’interface utilisateur pour les erreurs de logique.

En espérant que ceci vous aura aidé,

Scott

 

Haut de pageHaut de page

Microsoft réalise une enquête en ligne pour comprendre votre opinion sur le site Web de. Si vous choisissez de participer, l’enquête en ligne vous sera présentée lorsque vous quitterez le site Web de.

Souhaitez-vous y participer ?