Qu'est-ce que l'architecture N-Tier?

193

J'ai récemment vu de nombreuses offres d'emploi de développeurs qui incluent une phrase qui se lit plus ou moins comme ceci: "Doit avoir de l'expérience avec l'architecture N-Tier", ou "Doit être capable de développer des applications N-Tier".

Cela m'amène à me demander ce qu'est l'architecture N-Tier? Comment acquiert-on de l'expérience avec cela?

Joshua Carmody
la source
2
Il est intéressant de noter que cet autre post demande également ce qu'est l'architecture N-Tier, mais les réponses sont complètement différentes. stackoverflow.com/questions/7271165/… . Il semble qu'il existe une architecture N-Tier pour les logiciels et une architecture N-Tier pour le matériel.
Noremac

Réponses:

247

Wikipédia :

En génie logiciel, l'architecture à plusieurs niveaux (souvent appelée architecture à plusieurs niveaux) est une architecture client-serveur dans laquelle la présentation, le traitement des applications et la gestion des données sont des processus logiquement distincts. Par exemple, une application qui utilise un middleware pour traiter les demandes de données entre un utilisateur et une base de données utilise une architecture à plusieurs niveaux. L'utilisation la plus répandue de «l'architecture à plusieurs niveaux» fait référence à l'architecture à trois niveaux.

C'est discutable ce qui compte comme «niveaux», mais à mon avis, il doit au moins franchir la frontière du processus. Ou bien cela s'appelle des couches. Mais, il n'a pas besoin d'être sur des machines physiquement différentes. Bien que je ne le recommande pas, vous pouvez héberger le niveau logique et la base de données sur la même boîte.

texte alternatif

Modifier : Une implication est que le niveau de présentation et le niveau logique (parfois appelé couche de logique applicative) doivent traverser les limites de la machine "à travers le fil", parfois sur un réseau peu fiable, lent et / ou non sécurisé. C'est très différent d'une simple application de bureau où les données vivent sur la même machine que les fichiers ou d'une application Web où vous pouvez accéder directement à la base de données.

Pour la programmation à n niveaux, vous devez empaqueter les données sous une sorte de forme transportable appelée "ensemble de données" et les faire voler sur le fil. La classe DataSet de .NET ou le protocole de services Web comme SOAP sont quelques-unes de ces tentatives pour faire voler des objets sur le fil.

Eugene Yokota
la source
6
"3 niveaux" et "N niveaux" y a-t-il une différence?
chakrit
7
Cela dépend de la façon dont vous comptez les «niveaux» (logiques, physiques, etc.), mais vous pouvez facilement impliquer plus de 3 processus pour écrire une application. UI, UI platform (like Eclipse RCP), Web Services, BLL, DAL, Database, Authentication Services, Reporting Services, Analytical Services ...
Eugene Yokota
6
@chakrit: À mon époque (je suis vieux), plus de 2 niveaux (client-serveur) faisaient automatiquement référence à n niveaux.
Eduardo Molteni
@EugeneYokota - il est dit que les niveaux doivent représenter des sections physiques dans l'architecture (qui peuvent ou non être brevetées, par exemple dans un cluster), et les couches feront référence au regroupement logique des composants de l'application.
Eliran Malka
On m'a dit quelque chose qui ressemble beaucoup, mais les niveaux étant le niveau présentation - niveau service - niveau intégration / données. Savez-vous si ce sont juste des mots différents pour la même chose que l'architecture montrée ci-dessus ou quelque chose de différent? En ce qui concerne mes connaissances, elles semblent identiques mais je voudrais m'en assurer.
KayleighArianna
20

Il est basé sur la façon dont vous séparez la couche de présentation de la logique métier principale et de l'accès aux données ( Wikipedia )

  • 3 niveaux signifie couche de présentation + couche de composant + couche d'accès aux données.
  • Le niveau N est lorsque des couches supplémentaires sont ajoutées au-delà de celles-ci, généralement pour une modularité, une configurabilité ou une interopérabilité supplémentaires avec d'autres systèmes.
tsilb
la source
12
en fait, si l'un de ces niveaux est hébergé par une partie distante, par exemple un processeur de paiement, ce niveau peut ne pas être si "inutile"
Zak
1
Hmm. Il y a une énorme différence entre les «couches» et les «services». N-Tier est généralement utilisé pour indiquer que pour le niveau donné, tout ce qui est au-dessus doit le traverser pour accéder aux services de niveau inférieur. S'ils sont en parallèle, je les appellerais des services plutôt que des niveaux.
Dak
Lors de la construction du MCV habituel (une architecture à 3 niveaux), on peut décider d'implémenter le MCV avec des interfaces à double étage, de sorte que l'on peut en fait remplacer un niveau particulier sans avoir à modifier même une ligne de code. Nous en voyons souvent les avantages, par exemple dans les scénarios où vous souhaitez pouvoir utiliser plusieurs bases de données (auquel cas vous avez une double interface entre le contrôle et les couches de données). Lorsque vous le placez sur la couche d'affichage (présentation), vous pouvez (attendez !!) remplacer l'interface USER par une autre machine, automatisant ainsi l'entrée REAL (!!!)
David Svarrer
15

C'est un mot à la mode qui fait référence à des choses comme l'architecture Web normale avec, par exemple, Javascript - ASP.Net - Middleware - Couche de base de données. Chacune de ces choses est un "niveau".

1800 INFORMATION
la source
4

Les applications de données à N niveaux sont des applications de données qui sont séparées en plusieurs niveaux. Aussi appelées «applications distribuées» et «applications multiniveaux», les applications à n niveaux séparent le traitement en niveaux discrets qui sont répartis entre le client et le serveur. Lorsque vous développez des applications qui accèdent aux données, vous devez avoir une séparation claire entre les différents niveaux qui composent l'application.

Une application typique à n niveaux comprend un niveau de présentation, un niveau intermédiaire et un niveau de données. La façon la plus simple de séparer les différents niveaux d'une application à n niveaux consiste à créer des projets discrets pour chaque niveau que vous souhaitez inclure dans votre application. Par exemple, le niveau de présentation peut être une application Windows Forms, tandis que la logique d'accès aux données peut être une bibliothèque de classes située au niveau intermédiaire. En outre, la couche de présentation peut communiquer avec la logique d'accès aux données au niveau intermédiaire via un service tel qu'un service. La séparation des composants d'application en niveaux distincts augmente la maintenabilité et l'évolutivité de l'application. Il le fait en facilitant l'adoption de nouvelles technologies qui peuvent être appliquées à un seul niveau sans avoir à repenser la solution entière. En outre,

Tiré du site Web de Microsoft .

Robert Rocha
la source
4

Si je comprends la question, il me semble que la personne qui pose la question demande vraiment "OK, donc 3 niveaux est bien compris, mais il semble qu'il y ait un mélange de battage médiatique, de confusion et d'incertitude autour de ce que 4 niveaux, ou de généraliser, les architectures à N-niveaux signifient. Alors ... quelle est la définition du N-niveau qui est largement comprise et acceptée? "

C'est en fait une question assez profonde, et pour expliquer pourquoi, je dois aller un peu plus loin. Restez avec moi.

L'architecture classique à 3 niveaux: base de données, "logique métier" et présentation, est un bon moyen de préciser comment respecter le principe de séparation des préoccupations. Autrement dit, si je veux changer la façon dont "l'entreprise" veut servir les clients, je ne devrais pas avoir à parcourir l'ensemble du système pour comprendre comment le faire, et en particulier, les décisions les problèmes commerciaux ne devraient pas être dispersés bon gré mal gré à travers le code.

Maintenant, ce modèle a bien fonctionné pendant des décennies, et c'est le modèle classique «client-serveur». Avance rapide vers les offres cloud, où les navigateurs Web sont l'interface utilisateur pour un ensemble d'utilisateurs large et physiquement distribué, et on finit généralement par devoir ajouter des services de distribution de contenu, qui ne font pas partie de l'architecture classique à trois niveaux (et qui doivent être gérés à part entière).

Le concept généralise en ce qui concerne les services, les micro-services, la façon dont les données et le calcul sont distribués, etc. Que quelque chose soit ou non un `` niveau '' revient en grande partie à déterminer si le niveau fournit ou non une interface et un modèle de déploiement aux services qui se trouvent derrière (ou en dessous) du niveau. Un réseau de distribution de contenu serait donc un niveau, mais pas un service d'authentification.

Maintenant, allez lire d'autres descriptions d'exemples d'architectures à N niveaux avec ce concept à l'esprit, et vous commencerez à comprendre le problème. D'autres perspectives incluent les approches basées sur les fournisseurs (par exemple NGINX), les équilibreurs de charge sensibles au contenu, l'isolation des données et les services de sécurité (par exemple IBM Datapower), qui peuvent tous ou non ajouter de la valeur à une architecture, un déploiement et des cas d'utilisation donnés.

Dak
la source
3

Je crois comprendre que N-Tier sépare la logique métier, l'accès client et les données les uns des autres à l'aide de machines physiques distinctes. La théorie est que l'un d'eux peut être mis à jour indépendamment des autres.

GregD
la source
3

Les applications de données à N niveaux sont des applications de données qui sont séparées en plusieurs niveaux. Aussi appelées «applications distribuées» et «applications multiniveaux», les applications à n niveaux séparent le traitement en niveaux discrets qui sont répartis entre le client et le serveur. Lorsque vous développez des applications qui accèdent aux données, vous devez avoir une séparation claire entre les différents niveaux qui composent l'application.

Et ainsi de suite dans http://msdn.microsoft.com/en-us/library/bb384398.aspx

olyv
la source
3

Lors de la construction du MCV habituel (une architecture à 3 niveaux), on peut décider d'implémenter le MCV avec des interfaces à double étage, de sorte que l'on peut en fait remplacer un niveau particulier sans avoir à modifier même une ligne de code.

Nous en voyons souvent les avantages , par exemple dans les scénarios où vous souhaitez pouvoir utiliser plusieurs bases de données (auquel cas vous avez une double interface entre le contrôle et les couches de données).

Lorsque vous la placez sur la couche d'affichage (présentation), vous pouvez (maintenez !!) remplacer l'interface UTILISATEUR par une autre machine, automatisant ainsi l'entrée RÉELLE (!!!) - et vous pouvez ainsi exécuter des tests d'utilisabilité fastidieux des milliers de fois sans qu'aucun utilisateur ne doive taper et re-taper et re-taper encore et encore les mêmes choses.

Certains décrivent une telle architecture à 3 niveaux avec 1 ou 2 interfaces doubles comme une architecture à 4 ou 5 niveaux , ce qui implique implicitement les interfaces doubles.

D'autres cas incluent (mais ne sont pas limités à) le fait que - dans le cas de systèmes de bases de données partiellement ou entièrement répliqués, vous seriez pratiquement en mesure de considérer l'une des bases de données comme "maître", et ainsi vous auriez un niveau comprenant le maître et un autre comprenant la base de données esclave.

Exemple mobile

Par conséquent, multiniveau - ou N-niveau - a en effet quelques interprétations, alors que je m'en tiendrai sûrement aux niveaux 3 niveaux + supplémentaires comprenant des disques d'interface minces coincés entre les deux pour permettre lesdits échanges de niveaux, et en termes de test (particulièrement utilisé sur les appareils mobiles), vous pouvez désormais exécuter des tests utilisateur sur le logiciel réel, en simulant un utilisateur tapant d'une manière que la logique de contrôle ne peut pas distinguer d'un vrai utilisateur tapant. Ceci est presque primordial dans la simulation de tests utilisateur réels , dans la mesure où vous pouvez enregistrer toutes les entrées de l'OTA des utilisateurs, puis réutiliser la même entrée lors des tests de régression.

David Svarrer
la source
2

Lorsque nous parlons de niveaux, nous parlons généralement de processus physiques (ayant un espace mémoire différent).

Ainsi, dans le cas où les couches d'une application sont déployées dans différents processus, ces différents processus seront de différents niveaux.

Par exemple, dans une application à 3 niveaux, les discussions de niveau métier avec les mainframes (processus séparé) et les conversations avec Reporting Service (processus séparé), alors cette application serait à 5 niveaux.

Par conséquent, le nom générique est à n niveaux.

Sandeep Jindal
la source
2

depuis https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

Une architecture N-tier divise un pneu d'application en pneumatiques logiques et des niveaux physiques principalement et leur sont fracture des pièces secondaires. entrez la description de l'image ici

Les couches sont un moyen de séparer les responsabilités et de gérer les dépendances. Chaque couche a une responsabilité spécifique. Une couche supérieure peut utiliser les services d'une couche inférieure, mais pas l'inverse.

Les niveaux sont physiquement séparés, fonctionnant sur des machines distinctes. Un niveau peut appeler directement un autre niveau ou utiliser la messagerie asynchrone (file d'attente de messages). Bien que chaque couche puisse être hébergée dans son propre niveau, ce n'est pas obligatoire. Plusieurs couches peuvent être hébergées sur le même niveau. La séparation physique des niveaux améliore l'évolutivité et la résilience, mais ajoute également la latence de la communication réseau supplémentaire.

Une application traditionnelle à trois niveaux a un niveau de présentation, un niveau intermédiaire et un niveau de base de données. Le niveau intermédiaire est facultatif. Les applications plus complexes peuvent avoir plus de trois niveaux. Le diagramme ci-dessus montre une application avec deux niveaux intermédiaires, encapsulant différents domaines de fonctionnalité.

Une application à N niveaux peut avoir une architecture à couche fermée ou une architecture à couche ouverte:

In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.

Une architecture de couche fermée limite les dépendances entre les couches. Cependant, cela peut créer un trafic réseau inutile, si une couche transmet simplement les demandes à la couche suivante.

Manjitha teshara
la source
1

Une application à N niveaux est une application qui comprend plus de trois composants. Quels sont ces composants?

  • Cache
  • Files d'attente de messages pour un comportement asynchrone
  • Équilibreurs de charge
  • Serveurs de recherche pour rechercher des quantités massives de données
  • Composants impliqués dans le traitement de grandes quantités de données
  • Composants exécutant une technologie hétérogène communément appelée services Web, etc.

Toutes les applications sociales comme Instagram, Facebook, les services industriels à grande échelle comme Uber, Airbnb, les jeux multijoueurs massifs en ligne comme Pokemon Go, les applications avec des fonctionnalités sophistiquées sont des applications à n niveaux.

Sunny Sultan
la source
0

Martin Fowler démontrant clairement:

La superposition est l'une des techniques les plus courantes utilisées par les concepteurs de logiciels pour séparer un système logiciel complexe. Vous le voyez dans les architectures de machines, où les couches descendent d'un langage de programmation avec des appels de système d'exploitation dans les pilotes de périphériques et les jeux d'instructions CPU, et dans les portes logiques à l'intérieur des puces. La mise en réseau a FTP en couches sur TCP, qui est sur IP, qui est sur Ethernet.

En pensant à un système en termes de couches, vous imaginez les principaux sous-systèmes du logiciel disposés sous une forme de gâteau de couches, où chaque couche repose sur une couche inférieure. Dans ce schéma, la couche supérieure utilise divers services définis par la couche inférieure, mais la couche inférieure ne connaît pas la couche supérieure. De plus, chaque couche cache généralement ses couches inférieures aux couches supérieures, donc la couche 4 utilise les services de la couche 3, qui utilise les services de la couche 2, mais la couche 4 ne connaît pas la couche 2. (Toutes les architectures de couches ne sont pas opaques comme celle-ci , mais la plupart sont - ou plutôt la plupart sont pour la plupart opaques.)

La décomposition d'un système en couches présente un certain nombre d'avantages importants.

• Vous pouvez comprendre une seule couche comme un tout cohérent sans en savoir beaucoup sur les autres couches. Vous pouvez comprendre comment créer un service FTP au-dessus de TCP sans connaître les détails du fonctionnement d'Ethernet.

• Vous pouvez remplacer les couches par des implémentations alternatives des mêmes services de base. Un service FTP peut fonctionner sans modification via Ethernet, PPP ou tout autre équipement utilisé par une entreprise de câblodistribution.

• Vous minimisez les dépendances entre les couches. Si le câblodistributeur change son système de transmission physique, à condition qu'il fasse fonctionner IP, nous n'avons pas à modifier notre service FTP.

• Les calques sont de bons endroits pour la normalisation. TCP et IP sont des standards car ils définissent le fonctionnement de leurs couches.

• Une fois que vous avez créé une couche, vous pouvez l'utiliser pour de nombreux services de niveau supérieur. Ainsi, TCP / IP est utilisé par FTP, telnet, SSH et HTTP. Sinon, tous ces protocoles de niveau supérieur devraient écrire leurs propres protocoles de niveau inférieur. De la bibliothèque de Kyle Geoffrey Passarelli

La superposition est une technique importante, mais il y a des inconvénients.

• Les couches encapsulent bien certaines choses, mais pas toutes. En conséquence, vous obtenez parfois des modifications en cascade. L'exemple classique de cela dans une application d'entreprise en couches est l'ajout d'un champ qui doit s'afficher sur l'interface utilisateur, doit être dans la base de données et doit donc être ajouté à chaque couche intermédiaire.

• Des couches supplémentaires peuvent nuire aux performances. À chaque couche, les choses doivent généralement être transformées d'une représentation à une autre. Cependant, l'encapsulation d'une fonction sous-jacente vous donne souvent des gains d'efficacité qui font plus que compenser. Une couche qui contrôle les transactions peut être optimisée et accélérera ensuite tout. Mais la partie la plus difficile d'une architecture en couches est de décider quelles couches avoir et quelle devrait être la responsabilité de chaque couche.

Hamit YILDIRIM
la source