Différence entre l'architecture à 3 niveaux et MVC (modèle, contrôleur de vue) dans ASP.Net

J'aimerais savoir en quoi l'architecture à 3 niveaux diffère de MVC (Model, View Controller) dans ASP.Net car il me semble que la même architecture s'applique.

Dans trois niveaux que nous avons User Services Layer, BusinessLayeret DataAccessLayer, d'autre part , nous avons Model, Viewet Controller. Cela me semble la même architecture.

Quelqu'un peut-il expliquer si ce qui diffère vraiment des deux architectures, comment chaque couche diffère l'une de l'autre?

C'est comme demander quelle est la différence entre une pomme et un noyau de pomme. Ces deux architectures ne se remplacent pas l'une l'autre. Je pense qu'une vue plus précise est que l'architecture à 3 niveaux augmente MVC.

L'architecture MVC

• Modèles: ils représentent des "éléments" dans votre application. Cette couche est devenue un peu floue ces dernières années, comme je l'expliquerai plus tard.

• Vues: l'interface utilisateur. La chose avec laquelle l'utilisateur interagit.

• Contrôleurs: le code de programmation qui répond à l'utilisateur et aux changements dans la couche modèle

L'architecture à 3 niveaux

Avec l'architecture à 3 niveaux, vous disposez de couches avec différentes responsabilités.

• Services aux utilisateurs: (ou "services" en général) Cette couche concerne davantage la coordination de la récupération et des modifications de la couche "modèle". Des actions complexes en plusieurs étapes sont exécutées ici

• Couche métier: cela représente les règles métier gravées dans le code de programmation. Ce que veut "The Business" est appliqué dans cette couche.

• Couche d'accès aux données: une ou plusieurs classes chargées d'accéder à un magasin de données persistantes.

La seule partie de l'architecture à 3 niveaux qui recoupe MVC est la «couche métier». Les «modèles» dans MVC et la «couche métier» dans l'architecture à 3 niveaux tentent d'atteindre le même objectif.

Le "M" dans MVC est devenu flou

La couche "modèle" dans MVC s'est développée ces dernières années. D'après ce que j'ai vu, il existe deux, voire trois types de modèles:

1. Modèles de domaine: ils représentent les «choses» auxquelles «l'entreprise» se soucie - le domaine d'entreprise. Ces classes contiennent des données et toutes les procédures qui opèrent sur ces données afin d'appliquer les règles métier. Les modèles de domaine sont souvent liés à des tables dans une base de données. Cela semble correspondre à la "couche métier" de l'architecture à 3 niveaux.

2. Modèles de vue: ce sont des classes utilisées pour masser les données des modèles de domaine en quelque chose de plus agréable à la vue. Cela ne convient nulle part dans l'architecture à 3 niveaux, car les modèles de vue n'implémentent pas de logique métier, ni ne fournissent aucun type de service ou d'accès aux données.

3. Modèles commerciaux: dans les applications complexes, il est nécessaire de dissocier le modèle de domaine de la logique métier. Les modèles commerciaux contiennent des données et des procédures fonctionnant sur ces données pour implémenter des règles commerciales, et les modèles de domaine sont relégués à des «sacs de propriétés» - des objets qui contiennent uniquement des données mais ne contiennent aucun comportement. Les modèles de domaine deviennent une autre forme d'objet de transfert de données entre la base de données et l'application.

Nulle part dans MVC l'accès aux données n'est mentionné. Dans certains cas, vous verrez que l'accès aux données appartient à la couche "modèle" de MVC, qui, comme nous l'avons vu, n'est plus une couche claire. Vraiment, je vois une architecture à 3 niveaux associée à MVC pour créer une application entière. L'un augmente ou améliore l'autre:

• Des modèles
  • Modèles de domaine (MVC / 3 niveaux)
  • Voir les modèles (MVC)
  • (en option) Business Models (MVC / 3-tier)
• Vues (MVC)
• Contrôleurs (MVC)
• Accès aux données (3 niveaux)
• Services (3 niveaux)

Il y a une certaine intersection, mais ils sont en grande partie séparés, et ensemble sont utilisés pour découpler et isoler divers composants d'un système plus vaste.

Non, ils ne sont pas les mêmes.

MVC est un modèle de conception pour structurer le code d'interface utilisateur. Il pourrait être utilisé dans une architecture à trois niveaux, auquel cas le modèle appartiendrait à la couche des services aux utilisateurs. Mais il peut également être utilisé pour l'interface utilisateur dans une application qui n'est pas à trois niveaux - par exemple une calculatrice sans persistance sous-jacente, et donc sans couche d'accès aux données.

Dans une architecture à trois niveaux avec une interface MVC, les objets de domaine utilisés comme modèle seraient les objets de la couche métier, mais le modèle MVC ne spécifie pas vraiment de quel type d'objets il s'agit, mais uniquement leur rôle dans le modèle. est. Par exemple, dans la variante MVVM, les modèles sont des adaptateurs spécifiques à l'interface utilisateur au-dessus des objets de domaine. Dans ce cas, même le modèle appartient à la couche de service utilisateur.

Je sais qu'il y aura des tonnes de réponses différentes, mais je vais vous donner mon avis à ce sujet.

C'est la réponse la plus connue en génie logiciel "Ça dépend".

Essentiellement, si vous le regardez, outre les différentes implémentations et différences théoriques, ce sont des modèles très similaires avec des flux similaires.

Lorsque cela dépend de l'application que vous créez, une simple application Web peut n'avoir qu'une couche MVC parlant via un ORM à la base de données. Un plus complexe peut avoir MVC qui gère le front-end dans la couche utilisateur, avec des opérations exposées non-utilisateur plus complexes se produisant dans la couche BL, avec la couche de données composée de plusieurs sources.