Architecture MVC vs n-tier
Je me demandais quelle est exactement la différence entre MVC (qui est un modèle architectural) et une architecture à plusieurs niveaux pour une application. Je l'ai cherché mais je n'ai pas trouvé d'explication simple. Peut-être que je suis un peu naïf sur les concepts MVC, alors si quelqu'un peut expliquer la différence, ce serait formidable.
à votre santé
L'architecture à plusieurs niveaux a généralement chaque couche séparée par le réseau. C'EST À DIRE. la couche de présentation se trouve sur certains serveurs Web, puis celle-ci communique avec les serveurs d'applications principaux sur le réseau pour la logique métier, puis avec un serveur de base de données, à nouveau via le réseau, et le serveur d'applications appelle peut-être également certains services distants (par exemple, Authorize.net pour le traitement des paiements).
MVC est un modèle de conception de programmation dans lequel différentes parties de code sont responsables de la représentation du modèle, de la vue et du contrôleur dans certaines applications. Ces deux choses sont liées parce que, par exemple, la couche Modèle peut avoir une implémentation interne qui appelle une base de données pour stocker et récupérer des données. Le contrôleur peut résider sur le serveur Web et appeler à distance des serveurs d'applications pour récupérer des données. MVC résume les détails de la mise en œuvre de l'architecture d'une application.
N-tier fait simplement référence à la structure physique d'une implémentation. Ces deux sont parfois confondus car une conception MVC est souvent implémentée à l'aide d'une architecture à plusieurs niveaux.
Si une conception à 3 niveaux ressemblait à ceci:
Client <-> Middle <-> Data
le modèle MVC serait:
Middle
^ |
| v
Client <- Data
Ce qui signifie que:
- dans l’équivalent à 3 niveaux, la communication entre les couches est bidirectionnelle et passe toujours par le niveau intermédiaire
- en équivalent MVC, la communication est en nidirectionnelle; nous pourrions dire que chaque "couche" est mise à jour par celle de gauche et, à son tour, met à jour celle de droite - où "gauche" et "droite" sont simplement illustratifs
P.S. Client serait le View et milie le contrôleur
C'est quoi 
dire à propos de architecture à plusieurs niveaux
À première vue, les trois niveaux peuvent sembler similaires au concept MVC (Model View Controller); Cependant, topologiquement, ils sont différents. Une règle fondamentale dans une architecture à trois niveaux est que le niveau client ne communique jamais directement avec le niveau de données; Dans un modèle à trois niveaux, toutes les communications doivent passer par le niveau middleware. Conceptuellement, l'architecture à trois niveaux est linéaire. Cependant, l'architecture MVC est triangulaire: la vue envoie les mises à jour au contrôleur, le contrôleur met à jour le modèle et la vue est mise à jour directement à partir du modèle.
La seule similitude est que les deux modèles ont trois boîtes dans leurs diagrammes. Fondamentalement, ils sont complètement différents dans leurs utilisations. En fait, il n’est généralement pas possible de choisir le modèle à utiliser, mais les deux modèles peuvent être utilisés ensemble de manière nuisible. Voici une bonne comparaison des deux: http://allthingscs.blogspot.com/2011/03/mvc-vs-3-tier-pattern.html
Une règle fondamentale dans une architecture à trois niveaux est que le niveau client ne communique jamais directement avec le niveau de données; Dans un modèle à trois niveaux, toutes les communications doivent passer par le niveau middleware.
C’est l’architecture du paquebot. Cela répond à la question de savoir comment transmettre des informations entre un utilisateur et une base de données. Where as MVC est une architecture triangulaire: la vue envoie les mises à jour au contrôleur, le contrôleur met à jour le modèle et la vue est mise à jour directement à partir du modèle. Cela répond à des questions sur la manière dont une interface utilisateur gère les composants à l'écran.
Donnez-vous une pause. Et ne vous limitez pas à certains schémas lorsque vous résolvez des problèmes du monde réel. Rappelez-vous simplement quelques principes généraux, dont l'un est Séparation des préoccupations.
@Cherry Middle ware fonctionne plutôt comme un gestionnaire de requêtes ou un redirecteur dans MVC Pattern.
Je voudrais expliquer un peu au sujet de MVC, selon moi, le contrôleur de vue de modèle fonctionne comme ceci.
- Le client lance la session en demandant un service.
- Cette demande est reçue et traitée par le contrôleur (gestionnaire de demandes, redirecteur, etc.)
- Le contrôleur traite une information de base sur la demande et la redirige vers le modèle approprié qui peut remplir la demande de données.
- Le modèle remplit la demande en fonction des paramètres transmis par le contrôleur et renvoie les résultats au contrôleur. (Remarque: dans ce cas, j'aime bien effacer le fait que les données ne sont pas directement renvoyées au client dans la vraie architecture MVC, elles sont plutôt remplies et renvoyées au contrôleur.)
- Contrôleur que d'envoyer ces données à View (Client).
- Le client a le service demandé devant lui.
C'est tout à propos de MVC que je sais.
En plus d'être linéaire, une autre différence majeure qui n'a pas été suffisamment soulignée ici est que dans le modèle à N niveaux, N n'est pas nécessairement à trois niveaux! Il est le plus souvent implémenté en trois niveaux (présentation, application, données), la couche intermédiaire ayant deux sous-niveaux (logique métier et accès aux données). En outre, le modèle dans MVC peut contenir à la fois des données et une logique métier pour la manipulation de données, alors que celles-ci se situeraient dans des niveaux distincts sur plusieurs niveaux.
Il est préférable de définir une architecture à plusieurs niveaux à l'aide d'un diagramme de déploiement.
Une architecture MVC est mieux définie à l'aide d'un diagramme de séquence.
Les 2 ne sont pas identiques et ne sont pas liés et vous pouvez combiner les deux architectures ensemble. De nombreuses entreprises ont pris des mesures pour créer une architecture à plusieurs niveaux non seulement pour le déploiement et l'évolutivité, mais également pour la réutilisation du code.
Par exemple, vos objets d'entité commerciale peuvent avoir besoin d'être consommés par une application de bureau, un service Web exposé pour un client, une application Web ou une application mobile. Utiliser simplement une approche MVC ne vous aidera pas à réutiliser quoi que ce soit.
Conclusion: N-tier est une architecture, MVC un modèle de conception. Ce sont la même métaphore appliquée dans deux domaines différents.
Jerry: Voici un exemple simple de la façon dont les deux sont liés:
Niveau 1 - Se compose de modèles qui communiquent avec le niveau 2 via un type de service réseau ou similaire, ainsi que des contrôleurs pour gérer la validation des entrées, des calculs et autres opérations pertinentes pour les vues. Et il contient les vues elles-mêmes, bien sûr - qui peuvent être l'interface graphique d'une application de bureau ou l'interface Web d'une application Web.
Niveau 2 - Contient une sorte de service ou un autre moyen de recevoir des messages du Niveau 1. Ne sait pas/ne devrait pas connaître l'existence du Niveau 1, ne peut donc répondre qu'aux appels d'en haut - ne jamais demander par lui-même . Contient également toute la logique métier.
Niveau - Contient le modèle de domaine, la représentation objet de la base de données et toute la logique permettant de communiquer et de mettre à jour les entrées de base de données.
Dans un modèle à trois niveaux, toutes les communications doivent passer par le niveau intermédiaire. Conceptuellement, l'architecture à trois niveaux est linéaire. Cependant, l'architecture MVC [modèle-vue-contrôleur] est triangulaire: la vue envoie les mises à jour au contrôleur, le contrôleur met à jour le modèle et la vue est mise à jour directement à partir du modèle.