Quel est le modèle de l'architecture en couches dans asp.net?

Question

Je suis un développeur d'asp.net et je ne connais pas grand-chose aux motifs et à l'architecture. Je serai très reconnaissant si vous pouvez me guider s'il vous plaît ici.

Dans mes applications Web, j'utilise 4 couches.

1. projet de site Web (ayant des formulaires Web + code derrière les fichiers cs, contrôles utilisateur + code derrière les fichiers cs, pages maître + code derrière les fichiers cs)

2. CustomTypesLayer une bibliothèque de classes (ayant des types personnalisés, énumérations, DTO, constructeurs, get, set et validations)

3. BusinessLogicLayer une bibliothèque de classe (ayant toute la logique métier, les règles et tous les appels aux fonctions DAL)

4. DataAccessLay er une bibliothèque de classes (avec seulement des classes communiquant avec la base de données.)

-Mon interface utilisateur appelle simplement BusinessLogicLayer. BusinessLogicLayer le fait en lui-même et pour les données il appelle les fonctions DataAccessLayer.

-Les formulaires Web n'appellent pas directement DAL.

-CustomTypesLayer est partagé par tous les calques.

S'il vous plaît me guider est cette approche un modèle? Je pense que c'est peut-être MVC ou MVP mais les pages ont aussi du code derrière les fichiers qui me déroutent.

Si ce n'est pas le cas, est-ce proche d'un motif?

Answer 1

Ce n'est pas quatre couches, c'est trois couches, donc c'est une architecture à trois niveaux.

CustomTypesLayer n'est pas une couche du tout. Si tel était le cas, l'interface utilisateur utiliserait uniquement la couche de types personnalisés et ne communiquerait jamais directement avec la couche de gestion, et la couche d'accès aux données n'utiliserait jamais la couche de types personnalisés.

L'architecture à trois niveaux est un Multitier architecture

Answer 2

Jetez un oeil à l'Entity Framework ou LinqToSQL. Ils peuvent générer votre couche d'accès aux données automatiquement à partir de votre base de données. Cela vous épargnera beaucoup de travail (ennuyeux) et vous permettra de vous concentrer sur les couches intéressantes. Le code-behind n'a vraiment rien à voir avec l'architecture - il s'agit plutôt d'un style de codage. C'est un moyen de séparer la logique de la présentation. Toute architecture que vous mentionnez peut être utilisée avec ou sans code-behind.

Vous semblez décrire une architecture standard à trois niveaux. MVC est un modèle qui décrit comment vos couches et l'utilisateur interagissent. L'utilisateur demande une page (représentée par une vue), qui demande ses données au contrôleur. Le contrôleur communique avec votre couche de gestion (modèle) pour extraire les données correctes et les transmet à votre vue pour affichage. Si la vue est interactive, par exemple elle permet à l'utilisateur de mettre à jour quelque chose, cette action d'action utilisateur est renvoyée à votre contrôleur, qui appelle la méthode appropriée par rapport à la couche de gestion pour enregistrer la mise à jour dans la base de données.

Espérons que cela aide.

Answer 3

En ce qui concerne les modèles vont, je vous recommande la prise en main avec ces:

• Mes biggets préférés par un mile est le Dependency Inversion Principle (DIP), communément connu sous le nom (ou au moins très similaire à) Inversion of control (IoC) et Dependencey Injection; ils sont très populaires, donc vous devriez avoir aucun problème à trouver plus d'informations - obtenir des exemples. C'est vraiment bon pour extraire les implémentations d'accès aux données derrière les interfaces.
• Lazy Load est également utile. Fait intéressant, vous pouvez parfois vouloir faire le contraire - obtenir toutes les données dont vous avez besoin dans un big bang.
• Factory pattern est un très bien connu - pour une bonne raison.
• Facade pattern m'a également aidé à éviter les ennuis.

Wikipedia a une assez bonne liste de Software design patterns, en supposant que vous ne l'avez pas encore vu. Une dernière chose à garder à l'esprit est qu'il existe trois types de motifs de base (plus une quatrième catégorie pour le multithread/concurrent); il peut aider juste pour connaître ces catégories et de les garder à l'esprit quand vous faites quelque chose de cette nature, ils sont:

• Creational
• structurale
• comportementale

Answer 4

Scot Hanselman has a good article on this which is a must read. Votre CustomTypesLayer ressemble à votre domaine.