Qu'est-ce que n-tier signifie pour vous?

Question

J'ai remarqué au fil des années que différents développeurs appliquaient différents critères pour définir un niveau dans le développement d'un système à plusieurs niveaux. J'étais donc curieux de savoir quel était le consensus à ce niveau chez stackoverflow.

Les couches logiques séparées sont-elles suffisantes pour l'appeler un niveau distinct ou faut-il pouvoir le déployer sur un serveur distinct (physique ou virtuel) pour pouvoir l'appeler un niveau séparé?

Permettez-moi de formuler la question un peu différemment. Si le mécanisme d’appel ne peut être qu’un processus en cours, une unité d'exécution locale ou un appartement local, est-il possible d'affirmer qu'il s'agit de deux niveaux différents en fonction de l'organisation des classes en bibliothèques ou en packages?

Answer 1

Pour moi, le niveau physique signifie une partie du système, conçu pour être exécuté sur une machine physique différente. Oui, vous pouvez pointer votre chaîne de connexion à un autre serveur à tout moment, mais si votre DAL est trop bavarde, si elle a n + 1 et des problèmes d’ensemble d’enregistrements illimités, la latence du réseau vous tuera très vite.

La couche logique, en revanche, soutient les vertus de la séparation des préoccupations, de la cohésion et du couplage. Strictement, il n'est même pas nécessaire qu'il soit dans un assemblage séparé - un espace de noms fera l'affaire. N'appelez tout simplement pas les cours dont vous savez qu'ils ne devraient pas, NDepend vous aide.

Answer 2

Une couche logique distincte me suffit pour l'appeler un niveau. Il ne doit pas nécessairement être sur un serveur distinct, mais la séparation définie des autres couches le rend certainement possible.

A titre d'exemple, nous avions auparavant ce que j'appellerais un système à 3 niveaux (db, dll, pages asp) fonctionnant sur un seul serveur. Selon certaines définitions, il s’agit d’un système moniste. Nous avons maintenant la base de données fonctionnant sur un serveur séparé, la seule modification requise était une chaîne de connexion, mais cette solution serait-elle désormais à deux niveaux?

C’est la raison pour laquelle j’estime que le concept de niveau correspond davantage à la capacité de les exécuter sur des machines distinctes qu’au lieu de le devoir. Cela me semble plus cohérent.

Answer 3

  

Les concepts de couche et de niveau sont   souvent utilisé de façon interchangeable. cependant,   un point de vue assez commun est   qu'il y a bien une différence, et   qu'une couche est une structuration logique   mécanisme pour les éléments qui font   la solution logicielle, alors qu’un niveau   est un mécanisme de structuration physique   pour l'infrastructure du système

Référence .

Answer 4

Les couches constituent un mécanisme permettant de minimiser le couplage. ils sont logiques. Les niveaux sont conçus pour optimiser les performances ou éliminer les risques de sécurité; ils sont physiques. Ils ne sont vraiment pas les mêmes et je ne sais pas pourquoi les gens essaient de les utiliser indifféremment.

La grande majorité des applications Web sont à 3 niveaux par défaut (navigateur, serveur Web, serveur de base de données). La majorité des applications intranet sont à 2 niveaux (client, serveur de base de données). Mais dans les deux cas, je construis une couche d'interface utilisateur, une couche métier et une couche de données. Ils ont séparé les préoccupations et m'aident à structurer mon code de manière à ce qu'il soit maintenable. De plus, dans les deux cas, je finis généralement par les déployer tous sur une boîte; serveur Web ou poste de travail client. Donc, les couches et les niveaux ne correspondent même pas.

Answer 5

J'ai toujours pensé qu'un niveau correspond à une séparation physique dans une architecture, c'est-à-dire une machine. J'ai trouvé que les ces gars pensent la même chose récemment, c'est un très bon livre.

Mais pensant bien après avoir lu les autres réponses, je suis d’accord avec Garry sur cela .

Answer 6

Je suis d’accord avec Garry Shutler, mais j’ajouterais que de nombreux niveaux peuvent également exister dans un même processus / thread ou même dans le même assemblage. plus importante que la séparation physique (isolation matérielle, exécutable ou binaire) est la structure du code pour le développeur (IMHO). comme dans une application aspnet: la même dll peut contenir les trois niveaux: accès aux données, domaine et présentation.

Answer 7

Je dois dire que les définitions doivent être élaborées. Je considère généralement un niveau comme une séparation logique des fonctionnalités et des responsabilités et une couche comme l'exigence ou la capacité d'une séparation physique. Certaines couches peuvent avoir plusieurs niveaux et certains niveaux peuvent s'étendre sur plusieurs niveaux. J'utilise généralement un niveau de couche service capable de fournir une séparation physique si nécessaire et / ou souhaité via la configuration.

Donc, question / commentaire de suivi. S'il y a beaucoup de logique (métier ou autre) dans les procédures stockées de votre base de données, cela devrait-il également être considéré comme un niveau? Que faire si vous utilisez des fonctionnalités de votre moteur de base de données telles que Service Broker pour Microsoft SQL Server? Cela peut être considéré comme ayant deux niveaux lui-même.

De même, les services d'arrière-plan et / ou les démons, s'agit-il d'un niveau et / ou d'une couche distincts, ou appartiennent-ils à un groupe existant?

Answer 8

Consultez l'historique du terme "tier". en informatique. Personne n'a déclaré l'informatique à 1 niveau sur les ordinateurs de bureau, les ordinateurs de bureau et les ordinateurs centraux. Personne n'a parlé d'informatique à 2 niveaux pendant les jours client-serveur. Le 3-tiers est devenu le surnom architectural de client-serveur plus middleware (middleware orienté message et courtiers en transactions). Je pense que n-tier a été popularisé avec un autre terme "EAI" ou "Enterprise Architecture Integration". C’était précisément la même idée que les architectures orientées services, sauf que la plupart des implémentations des fournisseurs étaient soit propriétaires, basées sur des normes mais très coûteuses, soit les deux. Une fois que XML-RPC, SOAP et REST sont arrivés, ils l'appellent "Services Web". puis appliquez le principe EAI qui le sous-tend et passez à SOA - Architecture axée sur le service et Enterprise Service Bus

Ce que je veux dire, c'est qu'aucun de ces termes n'impliquait une séparation physique ... il s'agissait toujours de la séparation logique des fonctionnalités. Il se trouve que nombre de ces couches d’applications logiques ont été conçues pour être sans état, de sorte qu’elles PEUVENT être physiquement séparées aux fins d’évolutivité horizontale.