BLL est la couche de logique métier
DAL est la couche d’accès aux données
Architecture à trois niveaux de ASP.NET (DAL, BLL, UI)
Les graphismes représentent une structure en trois couches. Le web est la couche USL
Web –> BLL –> Dal
| | |
| V |
+–> modèle <—+
1. Architecture à trois niveaux
1. Couche de présentation (USL) : Elle représente principalement la méthode WEB, mais peut aussi être exprimée en mode WINFORM. Si la couche logique est assez robuste et bien établie, elle fonctionnera parfaitement peu importe la définition et la modification de la couche de performance.
2. Couche logique métier (BLL) : principalement pour des problèmes spécifiques, elle peut aussi être comprise comme le fonctionnement de la couche de données et le traitement logique de l’activité des données. Si la couche de données est les blocs de construction, alors la couche logique est la base de la couche.
3. Couche d’accès aux données (DAL) : Il s’agit principalement de la couche opérationnelle des données originales (sous forme de base de données, fichier texte ou autre forme de stockage des données), plutôt que des données originales, c’est-à-dire le fonctionnement des données, et non la base de données, plus précisément la couche de logique métier ou la couche de présentation
Fourniture de services de données.
2. Distinction spécifique
1. Couche de présentation : accepte principalement la demande de l’utilisateur et retourne les données, donnant ainsi au client l’accès à l’application.
2. Couche de logique métier : principalement responsable du fonctionnement de la couche de données, c’est-à-dire de la combinaison de certaines opérations de couche de données.
3. Couche d’accès aux données : Cela dépend principalement du fait que votre couche de données contient un traitement logique, en fait, ses fonctions effectuent principalement diverses opérations sur le fichier de données, sans avoir à se soucier d’autres opérations.
3. Résumé
La structure à trois couches est une approche strictement hiérarchique, c’est-à-dire que la couche d’accès aux données (DAL) ne peut être accessible que par la couche logique métier (BLL), et la couche logique métier uniquement par la couche présentation (USL). Certaines structures à trois couches ajoutent également d’autres couches telles que Factory et Model, qui sont en réalité une extension et une application sur la base de ces trois couches.
Un programme simple à trois niveaux inclut généralement plusieurs projets du modèle web DAL BLL, et leurs références communes sont les suivantes
1) RÉFÉRENCES WEB BLL, Modèle
2) BLL fait référence à DAL, modèle
3) Références DAL Modèle
4) Le modèle ne comporte aucune citation
En ce qui concerne l’architecture à trois niveaux, tout le monde sait qu’il s’agit de la couche performance (UI), de la couche logique métier (BLL) et de la couche d’accès aux données (DAL), et il existe de nombreuses façons de subdiviser chaque couche. Mais la façon d’écrire le code spécifique et dans quelle couche ces fichiers sont comptabilisés reste vague. Voici un exemple simple pour vous amener à pratiquer un projet d’architecture à trois couches, cet exemple n’a qu’une seule fonction, à savoir la gestion simple des utilisateurs.
D’abord, créez une solution vierge et ajoutez les éléments et fichiers suivants
1. Ajouter un projet d’application Web ASP.NET, le nommer UI, et créer un nouveau fichier de formulaire Web User.aspx (y compris User.aspx.cs)
2. Ajouter un projet ClassLibrary, le nommer BLL, et créer un nouveau fichier Class UserBLL.cs
3. Ajouter un projet BibliothèqueClasse, le nommer DAL, et créer un nouveau fichier Class UserDAL.cs. Ajoutez une référence SQLHelper. (C’est la classe d’accès aux données de Microsoft, ou vous pouvez écrire tout le code d’accès directement aux données.) J’utilise généralement la classe DataAccessHelper que j’écris.
4. Ajouter un projet ClassLibrary, le nommer Model, et créer un nouveau fichier de type Class UserModel.cs
5. Ajouter un projet ClassLibrary, le nommer IDAL, et créer un nouveau fichier Interface IUserDAL.cs
6. Ajouter un projet ClassLibrary et le nommer ClassFactory
Je crois que vous avez vu que ce n’est pas différent de l’exemple de Petshop, et que c’est plus simple, car j’apprends aussi l’architecture à trois niveaux via Petshop. Cependant, certains amis peuvent être vagues sur le niveau de ces projets et la relation entre eux, voici une explication un par un :
1. User.aspx et User.aspx.cs
Les deux documents (et les éléments auxquels appartient le fichier, ainsi que ceux ci-dessous, ne seront pas répétés) font partie de la couche de présentation. User.aspx est plus facile à comprendre car c’est une page d’affichage. User.aspx.cs certaines personnes pensent qu’il ne faut pas le compter, mais plutôt l’inclure dans la couche de logique métier. Si vous ne faites pas de couches, il n’y a aucun problème à User.aspx.cs laisser gérer la logique métier et même gérer la base de données, mais si vous faites des couches, cela ne devrait pas être fait. Dans une structure hiérarchique, User.aspx.cs ne devrait traiter que du contenu lié à l’affichage, et rien d’autre ne devrait être couvert.
Par exemple, si nous implémentons la fonction d’affichage des utilisateurs sous forme de liste, alors le travail d’extraction des informations est effectué par BLL, et après que l’interface utilisateur (dans ce cas, elle est User.aspx.cs) appelle BLL pour obtenir UserInfo, elle est liée au contrôle des données du User.aspx via du code pour réaliser l’affichage de la liste. Dans ce processus, User.aspx.cs il ne joue pas de rôle dans l’interface utilisateur, il sert uniquement à transmettre des données, et comme la plupart du codage est implémenté ainsi, certaines personnes estiment que User.aspx.cs ne devrait pas être compté comme UI, mais devrait être fusionné avec BLL pour le traitement logique. En approfondissant, une nouvelle exigence a été proposée pour ajouter une icône devant chaque utilisateur afin de représenter vivement son genre, et pour les moins de 18 ans, elle était représentée par une icône enfant. La réalisation de cette exigence est le tour de User.aspx.cs, et dans ce cas User.aspx.cs il a une réelle utilité.
2、NewBLL.cs
Ajoutez les méthodes suivantes :
IList public GetUsers() : Retourne une liste de toutes les informations utilisateur
public UserInfo GetUser(int UserId) : Renvoie les informations de l’utilisateur spécifié
public bool AddUser(UserInfoUser) : Informations utilisateur ajoutées
public bool ChangeUser(UserInfoUser) : met à jour les informations utilisateur
public void RemoveUser(int UserId) : Supprime les informations utilisateur
Ce fichier appartient à la couche logique métier et est dédié à la gestion des opérations liées à la logique métier. Beaucoup de gens peuvent penser que la seule utilisation de cette couche est de transférer les données de la couche performance vers la couche de données. Il existe en effet de nombreux cas de ce type, mais cela ne peut signifier que le projet est relativement simple, ou que la relation entre le projet lui-même et l’entreprise n’est pas étroitement intégrée (comme dans le MIS populaire actuel), donc la couche métier n’a rien à voir et ne joue qu’un rôle de retransmission. Mais cela ne signifie pas que la couche métier est dispensable ; à mesure que le projet augmente ou qu’il y a plus de relations commerciales, la couche métier reflétera son rôle.
L’erreur la plus probable ici est d’assigner le code d’opération des données à la couche logique métier et à la base de données comme couche d’accès aux données.
Par exemple, certains amis estiment que la couche BLL n’a pas de sens, mais ils téléchargent simplement les données DAL et les transmettent à l’interface sans aucun traitement. Regardez cet exemple
Couche BLL
SelectUser(UserInfoUserInfo) obtient les informations utilisateur en fonction du nom d’utilisateur ou de l’adresse e-mail reçue.
IsExist(UserInfoUserInfo) détermine si le nom d’utilisateur ou l’email spécifié existe.
Ensuite, le DAL fournit également la méthode correspondante pour l’appel BLL
SelectUser(UserInfoUserInfo)
IsExist(UserInfoUserInfo)
De cette façon, BLL ne joue qu’un rôle de transmission.
Mais si c’est le cas :
BLL. IsExist (Userinfo utilisateur)
{
Utilisateur UerInfo = DAL. SelectUser(User) ;
return (userInfo.Id != null) ;
}
Alors DAL n’a pas besoin d’implémenter la méthode IsExist(), et il y a du code de traitement logique dans BLL.
3、UserModel.cs
Entité, cette chose, vous pourriez penser que ce n’est pas facile à stratifier. Moi inclus, je l’ai compris ainsi : UI ?àModel ?àBLL ?àModel ?àDAL, donc on pense que le Modèle agit comme un pont pour la transmission des données entre les couches. Mais ici, nous ne pensons pas aux choses de façon simple, mais à la complexité.
Qu’est-ce que Modèle ? C’est rien! Il est dispensable dans une architecture à trois niveaux. C’est en fait la chose la plus basique en programmation orientée objet : les classes. Une table est une classe, une actualité est aussi une classe, int, string, doublie, etc. sont aussi des classes, ce n’est qu’une classe.
Ainsi, la position du modèle dans l’architecture à trois couches est identique au statut de variables telles que int et chaîne, et il n’a pas d’autre utilité, il est uniquement utilisé pour le stockage de données, mais il stocke des données complexes. Ainsi, si les objets de votre projet sont très simples, vous pouvez passer directement plusieurs paramètres sans modèle pour créer une architecture à trois couches.
Alors, pourquoi avoir besoin d’un modèle, et quels sont ses avantages ? Voici ce qui me vient à l’esprit en réfléchissant à une question, inséré ici :
Le modèle peut-il jouer un rôle plus important dans le passage des paramètres à chaque couche ?
Lors du passage de paramètres entre les couches, vous pouvez faire ce qui suit :
AddUser(userId,userName,userPassword,...,)
Cela peut aussi être ainsi :
AddUser(userInfo)
Laquelle de ces deux méthodes est la meilleure ? À première vue, c’est sûrement bien mieux la deuxième option.
Quand passer des paramètres entre des couches avec des types de variables normales (int, chaîne, guid, double), et que transmettre avec Modèle ? Les méthodes suivantes :
SelectUser(int UserId)
SelectUserByName(string nom d’utilisateur)
SelectUserByName(string username,string password)
SelectUserByEmail(chaîne email)
SelectUserByEmail(chaîne email, mot de passe en cadeau)
On peut la résumer ainsi :
SelectUser(userId)
SelectUser(user)
Ici, nous utilisons l’objet modèle utilisateur pour inclure quatre modes combinés : nom d’utilisateur, mot de passe et e-mail. UserId peut aussi être fusionné avec utilisateur, mais d’autres BLL du projet implémentent des interfaces avec des paramètres d’id, donc cet élément est également conservé.
userInfo est transmis, donc comment gérer cela doit être dans l’ordre donné, il y a un code spécifique à décider.
Ici, c’est traité dans cet ordre
D’abord, vérifiez si vous avez à la fois le nom d’utilisateur et le mot de passe, puis si vous avez à la fois l’adresse e-mail et le mot de passe, puis si vous avez un nom d’utilisateur, et enfin si vous avez un e-mail. Traité séquentiellement.
Ainsi, si un nouveau contenu est ajouté à l’avenir, la carte de membre (numéro), il n’est pas nécessaire de modifier l’interface, il suffit d’ajouter la prise en charge du numéro dans le code DAL, puis d’ajouter la performance et le traitement du contenu de la carte de membre au premier plan.
4、UserDAL.cs
public IList SelectUsers() : renvoie une liste de toutes les informations utilisateur
public UserInfo SelectUser(int UserId) : Renvoie les informations de confiance de l’utilisateur spécifié
public bool InsertUser(UserInfoUser) : Informations utilisateur ajoutées
public bool UpdateUser(UserInfoUser) : Met à jour les informations utilisateur
public void DeleteUser(int UserId) : Supprime les informations utilisateur
Ce que beaucoup de gens ne comprennent pas le plus, c’est la couche d’accès aux données, quelle partie est considérée comme la couche d’accès aux données ? Certaines personnes pensent que la base de données est la couche d’accès aux données, ce qui n’est pas clair sur la définition, DAL est la couche d’accès aux données plutôt que la couche de stockage des données, donc la base de données ne peut pas être cette couche. Le rôle de SQLHelper est de réduire le codage répétitif et d’améliorer l’efficacité du codage, donc si je suis habitué à me soucier de l’efficacité ou à utiliser une source de données non basée sur la base de données, je peux abandonner SQLHelper, une partie qui peut être jetée à volonté, comment pourrait-elle devenir une couche de l’architecture à trois couches ?
Elle peut être définie comme suit : le code lié aux opérations de source de données doit être placé dans la couche d’accès aux données, qui appartient à la couche d’accès aux données
5、IUserDAL
Interface de la couche d’accès aux données, c’est une autre chose indispensable, car Petshop l’apporte avec elle et ClassFactory Factory, donc certains projets font ces deux choses qu’ils doivent supporter plusieurs sources de données ou non, et certains ne construisent même pas ClassFactory mais se contentent d’IDAL, puis « IUserDAL iUserDal = new UserDAL() ; Je ne sais pas ce que ça veut dire. C’est complètement un tigre et non un anti-chien.
Beaucoup de gens ont une idée fausse ici, c’est-à-dire qu’il existe une telle relation : BLL ?àIDAL ?àDAL, pensant que IDAL agit comme un pont entre BLL et DAL, et que BLL appelle DAL via IDAL. Mais la réalité est que même si vous codez ainsi : « IUserDAL iUserDal = ClassFacotry.CreateUserDAL() ; Lors de l’exécution de « iUserDal.SelectUsers() », c’est en réalité l’instance UserDAL qui est exécutée, et non l’instance IUserDAL, donc la position d’IDAL dans la troisième couche est liée au niveau DAL.
À travers l’introduction ci-dessus, la hiérarchie de l’architecture à trois niveaux est essentiellement expliquée. En fait, j’ai un moyen de juger si l’architecture à trois couches est standard, c’est-à-dire si remplacer complètement l’une des trois couches n’affectera pas les deux autres, et si une telle structure répond essentiellement à la norme à trois couches (même si elle est plus difficile ^_^ à mettre en œuvre). Par exemple, si vous changez le projet de B/S à C/S (ou inversement), alors BLL et DAL n’ont pas besoin d’être modifiés sauf pour l’interface utilisateur ; Ou alors changer SQLServer en Oracle, remplacer simplement SQLServerDAL par OracleDAL, aucune autre opération n’est requise, etc. À l’origine, je voulais ajouter un code spécifique à l’article, mais je ne le juge pas nécessaire, si vous le jugez nécessaire, je l’ajouterai.
Résumé : Ne pensez pas qu’une couche soit inutile simplement parce qu’elle vous est inutile, ou qu’elle est particulièrement simple à implémenter, ou qu’elle abandonne, ou qu’elle l’utilise à d’autres fins. Tant que les calques sont réalisées, peu importe le nombre de couches, chaque couche doit avoir un objectif et une fonction claires, et ne doit pas être influencée par le processus réel, ce qui fait que le même type de fichier se retrouve dans différentes couches. Ne laissez pas la même couche implémenter des fonctions différentes. |
Publié sur 07/05/2015 10:53:35
|
|
|
