Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
LINQ to SQL est conçu spécialement pour une utilisation au niveau intermédiaire dans une couche d’accès aux données faiblement couplée (DAL) telle qu’un service web. Si le niveau de présentation est une page web ASP.NET, vous utilisez le LinqDataSource contrôle serveur Web pour gérer le transfert de données entre l’interface utilisateur et LINQ to SQL sur le niveau intermédiaire. Si le niveau de présentation n’est pas une page ASP.NET, le niveau intermédiaire et le niveau présentation doivent effectuer un travail supplémentaire pour gérer la sérialisation et la désérialisation des données.
Configuration de LINQ to SQL sur le niveau intermédiaire
Dans un service web ou une application de couche n, le niveau intermédiaire contient le contexte de données et les classes d’entité. Vous pouvez créer ces classes manuellement ou à l’aide de SQLMetal.exe ou du Concepteur relationnel d’objet, comme décrit ailleurs dans la documentation. Au moment du design, vous avez la possibilité de rendre les classes d’entité sérialisables. Pour plus d’informations, consultez How to : Make Entities Serializable. Une autre option consiste à créer un ensemble distinct de classes qui encapsulent les données à sérialiser, puis à projeter dans ces types sérialisables lorsque vous retournez des données dans vos requêtes LINQ.
Vous définissez ensuite l’interface avec les méthodes que les clients appelleront pour récupérer, insérer et mettre à jour des données. Les méthodes d’interface encapsulent vos requêtes LINQ. Vous pouvez utiliser n’importe quel type de mécanisme de sérialisation pour gérer les appels de méthode distants et la sérialisation des données. La seule exigence est que si vous avez des relations cycliques ou bidirectionnelles dans votre modèle objet, par exemple entre clients et commandes dans le modèle objet Northwind standard, vous devez utiliser un sérialiseur qui le prend en charge. Windows Communication Foundation (WCF) DataContractSerializer prend en charge les relations bidirectionnelles, mais le XmlSerializer utilisé avec les services web non WCF ne le fait pas. Si vous sélectionnez d’utiliser xmlSerializer, vous devez vous assurer que votre modèle objet n’a pas de relations cycliques.
Pour plus d’informations sur Windows Communication Foundation, consultez Windows Communication Foundation Services et WCF Data Services dans Visual Studio.
Implémentez vos règles métier ou une autre logique spécifique au domaine en utilisant les classes et méthodes partielles sur les DataContext et les classes d’entité pour s'intégrer aux événements d’exécution LINQ to SQL. Pour plus d’informations, consultez Implémentation de la logique métier de niveau N.
Définition des types sérialisables
Le niveau client ou de présentation doit avoir des définitions de type pour les classes qu’il recevra à partir du niveau intermédiaire. Ces types peuvent être les classes d'entité elles-mêmes ou des classes spéciales qui encapsulent uniquement certains champs des classes d'entité pour la communication à distance. Dans tous les cas, LINQ to SQL n’est pas préoccupé par la façon dont le niveau de présentation acquiert ces définitions de type. Par exemple, le niveau de présentation peut utiliser WCF pour générer automatiquement les types, ou avoir une copie d’une DLL dans laquelle ces types sont définis, ou il peut simplement définir ses propres versions des types.
Récupération et insertion de données
Le niveau intermédiaire définit une interface qui spécifie comment le niveau de présentation accède aux données. Par exemple GetProductByID(int productID), ou GetCustomers(). Sur le niveau intermédiaire, le corps de la méthode crée généralement une nouvelle instance du DataContext, exécute une requête sur une ou plusieurs de ses tables. Le niveau intermédiaire retourne ensuite le résultat sous la forme d’une IEnumerable<T>T classe d’entité ou d’un autre type utilisé pour la sérialisation. Le niveau de présentation n’envoie jamais ou ne reçoit jamais de variables de requête directement vers ou depuis le niveau intermédiaire. Les deux niveaux échangent des valeurs, des objets et des collections de données concrètes. Une fois qu’elle a reçu une collection, le niveau de présentation peut utiliser LINQ to Objects pour l’interroger si nécessaire.
Lors de l'insertion de données, le niveau de présentation peut construire un nouvel objet et l'envoyer au niveau intermédiaire, ou il peut laisser le niveau intermédiaire construire l'objet en fonction des valeurs qu'il fournit. En général, la récupération et l’insertion de données dans des applications à plusieurs niveaux ne diffèrent pas beaucoup du processus dans les applications de 2 niveaux. Pour plus d'informations, consultez Interroger la base de données et Effectuer et soumettre des modifications de données.
Suivi des modifications pour les mises à jour et les suppressions
LINQ to SQL prend en charge l’accès concurrentiel optimiste basé sur les horodatages (également nommés RowVersions) et sur les valeurs d’origine. Si les tables de base de données ont des horodatages, les mises à jour et les suppressions nécessitent peu de travail supplémentaire sur le niveau intermédiaire ou de présentation. Toutefois, si vous devez utiliser des valeurs d'origine pour les contrôles de concurrence optimistes, le niveau de présentation est chargé de suivre ces valeurs et de les renvoyer lorsqu'il procède à des mises à jour. Cela est dû au fait que les modifications apportées aux entités du niveau de présentation ne sont pas suivies sur le niveau intermédiaire. En fait, la récupération d’origine d’une entité et la mise à jour éventuelle effectuée sont généralement effectuées par deux instances complètement distinctes du DataContext.
Plus le nombre de modifications apportées au niveau de présentation est élevé, plus il devient complexe de suivre ces modifications et de les empaqueter au niveau intermédiaire. L’implémentation d’un mécanisme de communication des modifications est entièrement à l’application. La seule exigence est que LINQ to SQL doit recevoir les valeurs d'origine nécessaires pour les vérifications de concurrence optimiste.
Pour plus d’informations, consultez Les opérations de récupération de données et cuD dans les applications multiniveau (LINQ to SQL).