Partager via

Optimisation des interactions entre le niveau logique métier COM+ et le niveau présentation

  • Article

En règle générale, la latence entre les niveaux d’une application distribuée diffère considérablement. Les appels entre le niveau de présentation et le niveau logique métier sont souvent un ordre de grandeur plus lent que les appels entre le niveau entreprise et le niveau données. Par conséquent, l’état conservé est plus coûteux lors de l’appel au niveau logique métier.

Les rubriques suivantes expliquent comment passer des données entre les niveaux de présentation et de logique métier :

Passage de paramètres

Pour un ensemble d’informations donné à passer entre le niveau de présentation et le niveau logique métier, vous pouvez avoir une seule ligne, plusieurs lignes ou une combinaison d’une seule ligne (comme un en-tête) et de plusieurs lignes de données détaillées. Le moyen le plus efficace de transmettre ces informations entre les niveaux consiste à utiliser un seul appel de méthode. Cet appel unique gérerait l’ensemble des informations à transmettre. Cela est nécessaire, sauf si vous choisissez de contrôler la transaction à partir du niveau de présentation (et de rendre tous les traitements de transaction dans le niveau de présentation identiques en fonction). Microsoft recommande de ne pas effectuer de transactions à partir du niveau présentation, car les appels entre ce niveau et le niveau logique métier sont généralement les plus lents dans une application multiniveau.

Une façon de créer une telle méthode consiste à passer une seule ligne d’informations en tant que paramètres et à passer plusieurs lignes en tant que jeux d’enregistrements ADO. Les recordsets sont au cœur de la méthodologie d’accès aux données ADO de Microsoft. L’utilisation des jeux d’enregistrements ADO vous permet de passer toutes les informations relatives à une seule transaction en une seule étape.

Options de transmission de données

Il existe d’autres options à prendre en compte lors du passage de données. Il s’agit notamment de l’utilisation d’une liste de paramètres et de jeux d’enregistrements ADO (comme indiqué ci-dessus), uniquement des jeux d’enregistrements ADO, des chaînes encodées XML ou des tableaux de structures. Cette section décrit chacune de ces options.

Le tableau suivant montre les zones où une attention supplémentaire doit être prise lors de l’utilisation de l’une des quatre différentes possibilités de transmission d’arguments. Un « X » représente les domaines où les compromis doivent être compris et évalués par rapport aux besoins de chaque projet. Essayez de ne pas prendre de décisions de transmission d’arguments par composant. Les avantages d’un modèle de programmation cohérent tout au long d’un projet dépassent de loin tout avantage de l’optimisation par méthode ou par composant dans toutes les circonstances, sauf dans les circonstances les plus extrêmes. Les colonnes sont décrites dans la liste qui suit le tableau.

  Accès concurrentiel WAN Déploiement Complexité
Entrée Valeur
Recordsets
 X
 X
 X
XML
 X
 X
 X
Tableaux
 X
 X
 X

Les quatre colonnes définissent les zones pour lesquelles watch lorsque vous utilisez cette option pour passer des paramètres.

  • La colonne Concurrency représente la nécessité de coder ou de fournir un mécanisme qui gère les conditions de verrouillage sur les opérations de mise à jour. Étant donné que les méthodes qui effectuent des sauvegardes peuvent représenter des mises à jour, des problèmes d’accès concurrentiel peuvent survenir. Deux types de verrouillage sont prédominants optimistes et pessimistes. Les verrous pessimistes empêchent un utilisateur d’obtenir des données pour la mise à jour, tandis qu’un autre utilisateur a le potentiel d’effectuer une mise à jour. Le verrouillage optimiste prend en charge un grand nombre plus d’utilisateurs en négociant contre la probabilité que deux utilisateurs mettent à jour le même document en même temps. Le verrouillage optimiste appelle à vérifier que les données stockées correspondent aux données au moment où une copie des données a été consultée pour modification. Les jeux d’enregistrements ADO fournissent une prise en charge automatique du verrouillage optimiste. Les scénarios de mise à jour impliquant des listes de paramètres à ligne unique ne fournissent pas une prise en charge suffisante pour la vérification de la concurrence. Xml souffre de ce même problème, car aucune conscience de verrouillage n’est présente dans les données XML.
  • La colonne WAN représente les conditions dans lesquelles il peut y avoir une contention de transmission sur un réseau étendu (WAN). Lorsque le WAN ne dispose pas d’une capacité suffisante pour gérer toutes les données déplacées à un moment donné, les utilisateurs de l’application rencontrent des retards de temps de réponse. Pour prendre en charge l’accès concurrentiel optimiste, les jeux d’enregistrements ADO déconnectés transmettent deux copies des données du serveur au client. La deuxième copie est utilisée par le client pour déterminer le plus petit ensemble de lignes de mise à jour à transmettre lors de la validation d’une modification. Bien que cela réduit le trafic du niveau de présentation vers les données, la charge supplémentaire de la deuxième copie peut être importante. L’utilisation de jeux d’enregistrements comme seul moyen de transmettre toutes les informations entraîne donc le passage de deux fois plus de données entre les niveaux que nécessaire, sauf lorsque l’ensemble de lignes de mise à jour est renvoyé au niveau données à partir d’un niveau de présentation.
  • La colonne Déploiement représente les problèmes associés à la transmission de données lorsque une technologie spéciale est requise à la fois du côté de l’appelant et du côté des composants du réseau. Par exemple, l’utilisation de jeux d’enregistrements ADO nécessite la présence de composants ADO sur le client et le serveur. Les analyseurs XML doivent également être présents des deux côtés, afin d’éviter d’avoir à coder des analyseurs dans vos applications.
  • La colonne Complexité est indiquée pour les quatre choix et est une question de préférence ou d’expérience de modèle de programmation antérieure qui peut être déjà établie dans votre organization de développement. Certaines personnes trouvent que la transmission de paramètres est fastidieuse et pensent qu’elle ajoute trop de complexité au problème de programmation. Le fait de suivre le paramètre que vous gérez et de les rendre visibles dans une seule fenêtre d’édition peut créer une complexité logistique que certains développeurs trouvent ingérable.

La méthode de passage de paramètres peut également avoir des compromis, tels que les suivants :

  • Les paramètres peuvent impliquer la gestion de plusieurs arguments et types d’arguments, ainsi que la nécessité de décider quand il convient de faire d’un jeu d’enregistrements un paramètre.
  • Les jeux d’enregistrements ADO peuvent réduire les relations hiérarchiques dans les paramètres de méthode à un ou deux arguments. Cela simplifie considérablement le modèle de programmation et prend en charge l’ajout de colonnes ultérieurement, mais elle masque également la hiérarchie des informations. Le farce d’informations dans un jeu d’enregistrements ADO et leur extraction ultérieure implique de connaître les noms de chaque colonne ou de connaître l’ordre des colonnes. Cette situation peut ajouter de la complexité pour d’autres développeurs de composants ou d’applications sur le projet.
  • XML est un tour différent de la complication de hiérarchie masquée mentionnée ci-dessus. Le programmeur doit comprendre l’utilisation d’un analyseur XML pour accéder aux informations et doit souvent connaître les noms de chaque élément du jeu de données avant de trouver le jeu de données.
  • Les tableaux de structures introduisent la nécessité d’une compréhension commune des informations transmises par l’appelant et le composant. Ce besoin d’une carte partagée entre deux éléments système peut entraîner des difficultés lors du traitement de différentes versions de composants. Bien que la signature de la méthode ne change pas, les modifications apportées aux informations attendues peuvent rendre les programmes appelants incompatibles.

Étant donné que les problèmes de complexité associés aux quatre méthodes de passage de paramètres sont si similaires, il est discutable qu’il existe une possibilité de simplification significative associée à une sélection.

Utilisation d’un modèle d’usine pour transmettre des données

Un point de conception important est la facilité d’utilisation. Au moment où vous avez décidé d’utiliser des jeux d’enregistrements ADO pour transmettre un ensemble structuré de détails au niveau de présentation, vous avez introduit un problème de complexité. Les programmeurs de niveau présentation doivent comprendre la structure de ces jeux d’enregistrements. Un problème plus complexe peut se produire lorsque vous avez besoin de plusieurs détails pour qu’un jeu de données soit transmis dans un jeu d’enregistrements. Pour simplifier les choses, vous devez envisager de créer une méthode de fabrique de jeu d’enregistrements chaque fois que vous avez l’intention d’exiger que les données soient transmises dans des jeux d’enregistrements ADO structurés.

La fabrique de jeu d’enregistrements doit retourner un jeu d’enregistrements déconnecté vide mais accessible en écriture à l’appelant. Ce jeu d’enregistrements doit avoir les champs appropriés (noms et types de données) déjà configurés afin que le client appelant n’ait pas besoin de savoir comment fabriquer le recordset. Cette approche est souvent appelée modèle de fabrique et est un modèle de solution courant qui résout la nécessité de créer un objet d’une complexité donnée sans avoir à connaître les nuances de sa création.

Des choix de conception simples, tels que le choix du même nom de paramètre pour le même élément de données pour chaque méthode où ces informations sont transmises, permettent d’examiner facilement une méthode et de savoir ce qui est attendu. S’assurer que l’ordre dans lequel les arguments similaires sont passés est cohérent dans toute une famille de méthodes fournit un point de confort qui applique un modèle cohérent.

Optimisation des interactions entre le niveau logique MÉTIER COM+ et le niveau Données