Partager via


Utilisation d’un modèle d’architecture Three-Tier

Le modèle d’architecture à trois niveaux, qui est l’infrastructure fondamentale du modèle de conception logique, segmente les composants d’une application en trois niveaux de services. Ces niveaux ne correspondent pas nécessairement aux emplacements physiques sur différents ordinateurs d’un réseau, mais plutôt aux couches logiques de l’application. La façon dont les éléments d’une application sont distribués dans une topologie physique peut changer, en fonction de la configuration système requise.

Voici de brèves descriptions des services alloués à chaque niveau :

  • Le niveau présentation, ou couche services utilisateur, donne à un utilisateur un accès à l’application. Cette couche présente des données à l’utilisateur et autorise éventuellement la manipulation et l’entrée de données. Les deux types main d’interface utilisateur pour cette couche sont l’application traditionnelle et l’application web. Les applications web contiennent désormais souvent la plupart des fonctionnalités de manipulation de données utilisées par les applications traditionnelles. Pour ce faire, utilisez du code HTML dynamique et des sources de données côté client et des curseurs de données.

    Notes

    Dans une application à trois niveaux, l’application côté client sera plus skin que l’application client-serveur, car elle ne contiendra pas les composants de service situés maintenant dans le niveau intermédiaire. Cela entraîne moins de surcharge pour l’utilisateur, mais plus de trafic réseau pour le système, car les composants sont distribués entre différentes machines.

     

  • La couche intermédiaire, ou couche de services métier, se compose de règles métier et de données. Également appelé niveau de logique métier, le niveau intermédiaire est l’endroit où les développeurs COM+ peuvent résoudre des problèmes métier critiques et obtenir des avantages majeurs en matière de productivité. Les composants qui composent cette couche peuvent exister sur un ordinateur serveur pour faciliter le partage des ressources. Ces composants peuvent être utilisés pour appliquer des règles d’entreprise, telles que des algorithmes métier et des réglementations légales ou gouvernementales, et des règles de données, qui sont conçues pour maintenir la cohérence des structures de données au sein de bases de données spécifiques ou multiples. Étant donné que ces composants de niveau intermédiaire ne sont pas liés à un client spécifique, ils peuvent être utilisés par toutes les applications et peuvent être déplacés vers différents emplacements, en fonction du temps de réponse et d’autres règles. Par exemple, des modifications simples peuvent être placées côté client pour réduire les allers-retours réseau, ou des règles de données peuvent être placées dans des procédures stockées.

  • La couche Données, ou couche de services de données, interagit avec les données persistantes généralement stockées dans une base de données ou dans un stockage permanent. Il s’agit de la couche d’accès SGBD réelle. Il est accessible via la couche services métier et, à l’occasion, par la couche services utilisateur. Cette couche se compose de composants d’accès aux données (plutôt que de connexions SGBD brutes) pour faciliter le partage des ressources et permettre aux clients d’être configurés sans installer les bibliothèques SGBD et les pilotes ODBC sur chaque client.

Pendant le cycle de vie d’une application, l’approche à trois niveaux offre des avantages tels que la réutilisation, la flexibilité, la facilité de gestion, la maintenabilité et la scalabilité. Vous pouvez partager et réutiliser les composants et services que vous créez, et les distribuer sur un réseau d’ordinateurs en fonction des besoins. Vous pouvez diviser des projets volumineux et complexes en projets plus simples et les affecter à différents programmeurs ou équipes de programmation. Vous pouvez également déployer des composants et des services sur un serveur pour vous aider à suivre les modifications, et vous pouvez les redéployer à mesure que la base d’utilisateurs, les données et le volume de transactions de l’application augmentent.

Le modèle logique : définition et planification de l’application