Maison  >  Article  >  développement back-end  >  Comprendre l'architecture multicouche dans ASP.NET

Comprendre l'architecture multicouche dans ASP.NET

巴扎黑
巴扎黑original
2017-08-03 13:13:372818parcourir

L'architecture multicouche d'Asp.net vise principalement à résoudre la relation entre la couche de données, la couche logique, la couche de présentation, etc. Voici comment procéder : Créez d’abord une classe de base DataCore. La classe de base encapsule certaines opérations de base de la base de données de bas niveau, telles que la connexion à la base de données, l'appel de procédures stockées, etc.

Beaucoup de gens ont du mal à développer des applications multi-niveaux. Regardons un exemple : pour une petite entreprise ne comptant qu'une ou deux personnes, une personne peut effectuer plusieurs tâches telles que patron, caissier, comptable, marketing, ventes, développement, etc. en même temps. Pour une grande entreprise, il y aura une division stricte du travail. Chaque personne n’effectue qu’une partie du travail et doit coopérer les unes avec les autres pour assurer un fonctionnement normal. Le programme de développement précédent était similaire à celui d'une petite entreprise. Toutes les fonctions, de l'interface utilisateur à l'accès à la base de données, étaient complétées sur une seule page. Les inconvénients sont les suivants :

1. Il est difficile à développer et à mettre en œuvre. plusieurs personnes. Développement collaboratif

2. Une fois la base de données ou les règles modifiées, la page entière peut devoir être modifiée, augmentant les coûts de maintenance

3. Parce que toutes les fonctions sont mélangées, la réutilisabilité du programme est possible. pauvre. Si vous développez un nouveau projet, vous devez presque réécrire le code

Afin de résoudre ce problème, les gens ont avancé le concept d'"application multi-tiers", qui est essentiellement similaire à une grande entreprise avec autorité claire et division du travail sur la page. Placez les fonctions telles que l'accès aux données et les règles commerciales dans des fichiers spéciaux. Les plus populaires sont l'architecture à deux niveaux, l'architecture à trois niveaux et MVC.

1. Architecture à deux niveaux

L'architecture à deux niveaux divise le programme en une couche d'interface utilisateur et une couche d'accès aux données. Son essence est de placer le code qui accède à la base de données dans la couche d'accès aux données, et la couche d'interface utilisateur exploite la base de données via la couche d'accès aux données. La relation d'interaction est la suivante : ("<--->" représente une flèche à double sens)

Interface utilisateur<---> Accès aux données<--->

2. Architecture à trois niveaux

L'architecture à trois niveaux signifie que la logique métier dans l'architecture à deux niveaux est séparée de la couche d'accès aux données et devient une couche distincte couche de logique métier. Après avoir divisé le programme en trois couches, la couche d'accès aux données exploite uniquement la base de données, tandis que la couche de logique métier est responsable des divers traitements des données.

Il comprend principalement 4 composants du niveau supérieur : DAL (couche de traitement des données), BLL (couche de logique métier), UI (couche d'interface utilisateur) et Model (modèle d'entité). Les trois premiers constituent ce que l’on appelle souvent la structure à trois niveaux.
1) Couche d'accès aux données (database access layer, DAL) : Parfois également appelée couche de persistance, sa fonction est principalement responsable de l'accès à la base de données. Pour faire simple, il s'agit d'implémenter les opérations de sélection, d'insertion, de mise à jour et de suppression sur la table de données. Si vous souhaitez ajouter des éléments ORM, cela inclura le mappage entre les objets et les tables de données, ainsi que la persistance des entités d'objets
2) Couche de logique métier (BLL) : c'est le cœur de l'ensemble du système ; métier (domaine) de ce système ;
3) Couche de présentation (couche d'interface utilisateur, UIA) : C'est la partie UI du système et est responsable de l'interaction entre l'utilisateur et l'ensemble du système. Dans cette couche, l’idéal est que la logique métier du système ne soit pas incluse. Le code logique dans la couche de présentation n'est lié qu'aux éléments d'interface ;
4) Couche de modèle d'entité (Modèle) : contient toutes les informations de données, qui existent sous la forme de diverses instances d'entité. C'est le niveau de base de l'ensemble du système ;

La structure parfaite à trois niveaux devrait être : modifier la couche de présentation sans modifier la couche logique, et modifier la couche logique sans modifier la couche d'accès aux données. Atteindre un certain degré de découplage.

L'architecture à trois niveaux rend principalement la structure du projet plus claire et la division du travail plus claire, ce qui est propice à la maintenance et aux mises à niveau ultérieures. Il résout le problème de l'encapsulation du code à différentes étapes de chaque processus opérationnel métier dans l'ensemble de l'application, permettant aux programmeurs de se concentrer davantage sur le traitement de la logique métier d'une étape spécifique. Cependant, les performances ne peuvent pas être améliorées, car lorsque le module de sous-programme n'est pas terminé, le module de programme principal ne peut être qu'en état d'attente. Cela montre que diviser l'application en couches entraînera une certaine perte de vitesse d'exécution. Mais du point de vue de l’efficacité du développement de l’équipe, on peut ressentir un effet très différent.

Il convient de noter que bien que l'architecture à trois niveaux présente de nombreux avantages, si votre programme est très simple, ou s'il ne sera certainement pas réutilisé à l'avenir, ou s'il n'est pas nécessaire d'utiliser une architecture à deux niveaux architecture, peut-être utiliser une architecture à deux niveaux ou ordinaire. La vitesse de développement du programme sera plus rapide. Cela doit être traité au cas par cas en fonction de la situation réelle.

3.MVC

M est le modèle (couche de modèle), qui est principalement responsable de la logique métier et de l'interaction avec la base de données ;
V est la vue (couche de vue), qui est principalement utilisée pour afficher les données et soumettre des données ; est le contrôleur ), principalement utilisé pour capturer les requêtes et contrôler le transfert des requêtes ;

MVC est constitué de plusieurs modules avec différentes fonctions divisées dans la couche de visualisation de l'application (structure BS), principalement pour résoudre le problème de l'interface utilisateur de l'application. Concernant le remplacement de style, la page HTML qui affiche les données doit être séparée autant que possible du code métier.

4. La différence entre la structure à trois couches et MVC

Vous pouvez comprendre la différence en regardant l'image :

Figure 2. La différence entre MVC et l'architecture à trois niveaux

L'architecture à trois niveaux est composée de la couche d'interface (UI), de la couche de logique métier (BLL) et des données couche d'accès (DAL), tandis que MVC est la couche modèle (M). Elle est composée de la couche d'interface (View) et de la couche de contrôle (Controller), et elles ne correspondent pas les unes aux autres.

Si vous insistez pour les faire correspondre, alors l'interface utilisateur dans l'architecture à trois niveaux correspond à la vue dans MVC, qui est utilisée pour afficher et obtenir les données d'interface ; la couche modèle dans MVC Ils sont tous utilisés pour traiter les données transmises par la couche supérieure et les données obtenues à partir de la base de données ; le contrôleur dans MVC fait tout au plus partie de l'interface utilisateur dans l'architecture à trois niveaux.

5. Relation de référence d'architecture à trois niveaux

Couche modèle : ne référence aucun projet

Couche DAL : référence le modèle, en lisant le web. L'assembly dans config charge l'instance de la classe et la renvoie à BLL pour utilisation ;
Couche BLL : fait référence au modèle, DAL
Couche UI : fait référence au modèle, BLL ; La méthode se trouve dans le gestionnaire de ressources. Cliquez avec le bouton droit sur le fichier projet et ajoutez une référence. Sélectionnez la balise du projet dans la boîte de dialogue contextuelle, sélectionnez la bibliothèque de classes appropriée et cliquez sur OK. Ajoutez ensuite l'utilisation de "espace de noms de classe référencé" dans le fichier de projet.

Le projet a ajouté une référence, mais le fichier de bibliothèque de classes spécifié n'est toujours pas trouvé. Vous pouvez vérifier :

1. Y a-t-il une erreur de syntaxe dans le projet référencé et s'il faut l'ajouter en utilisant "namespace". au fichier d'en-tête.

2. Lors de l'ajout d'une bibliothèque de classe, si la bibliothèque de classe est publique.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn