Conventions de dénomination DAL, BAL et UI Layer [fermé]

Je développe une application Web typique avec les couches suivantes

1. Couche UI (MVC)
2. Couche de logique métier (BAL)
3. Couche d'accès aux données (DAL)

Chaque couche a son propre objet DTO, y compris BAL et DAL. Mes questions à ce sujet sont les suivantes

1. Le DTO renvoyé par le DAL est simplement converti en DTO correspondant dans la BAL et envoyé à la couche d'interface utilisateur. Les attributs et la structure des objets DTO sont identiques dans certains cas. Dans de tels scénarios, il est préférable de simplement renvoyer le DTO dans le DAL à la couche d'interface utilisateur sans inclure d'objet intermédiaire.

2. Quel est le meilleur moyen de nommer ces objets DTO et les autres objets de chaque calque? Devrais-je utiliser un préfixe tel que DTOName, ServiceName? La raison pour laquelle je demande à utiliser un préfixe est que si les classes de ma solution n'entrent pas en conflit avec d'autres classes du Framework et avec un préfixe, il m'est plus facile de comprendre à quelle classe appartient chaque classe.

Préface

Espérons que cela soit évident, mais ... dans les espaces de noms suggérés ci-dessous, vous devez remplacer MyCompanyet MyProjectpar les noms réels de votre société et de votre projet.

DTO

Je recommanderais d'utiliser les mêmes classes DTO sur toutes les couches. Moins de points d'entretien de cette façon. Je les mets généralement sous un MyCompany.MyProject.Modelsespace de noms, dans leur propre projet VS du même nom. Et je les nomme généralement simplement d'après l'entité du monde réel qu'ils représentent. (Idéalement, les tables de base de données utilisent également les mêmes noms, mais il est parfois judicieux de configurer le schéma un peu différemment.)

Exemples: Person, Address,Product

Dépendances: Aucune (autre que les bibliothèques standard .NET ou helper)

DAL

Ma préférence personnelle ici est d’utiliser un ensemble un pour un de classes DAL correspondant aux classes DTO, mais dans un MyCompany.MyProject.DataAccessespace de noms / projet. Les noms de classe se terminent ici par un Enginesuffixe afin d'éviter les conflits. (Si vous n'aimez pas ce terme, un DataAccesssuffixe fonctionnerait également. Soyez juste cohérent avec ce que vous choisissez.) Chaque classe fournit des options CRUD simples touchant la base de données, en utilisant les classes DTO pour la plupart des paramètres d'entrée et types de retour (à l'intérieur générique Listquand il y en a plus d'un, par exemple, le retour d'une Find()méthode).

Exemples: PersonEngine, AddressEngine,ProductEngine

Les dépendances: MyCompany.MyProject.Models

BAL / BLL

Également un mappage un pour un ici, mais dans un MyCompany.MyProject.Logicespace de nom / projet et avec des classes obtenant un Logicsuffixe. Cela devrait être la seule couche qui appelle le DAL! Les classes ici ne sont souvent qu'une simple transmission au DAL, mais si et quand des règles métier doivent être mises en œuvre, c'est l'endroit idéal.

Exemples: PersonLogic, AddressLogic,ProductLogic

Dépendances: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

S'il existe une couche d'API de services Web, j'utilise la même approche un pour un, mais dans un MyCompany.MyProject.WebApiespace de noms / projet, avec Servicesle suffixe de classe. (Sauf si vous utilisez l’API Web ASP.NET, auquel cas vous utiliseriez bien sûr le Controllersuffixe à la place).

Exemples: PersonServices, AddressServices,ProductServices

Dépendances: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(jamais contournement en appelant le DAL directement!)

Une observation sur la logique d'entreprise

Il semble de plus en plus courant que les gens omettent le BAL / BLL et mettent en place la logique métier dans une ou plusieurs des autres couches, là où cela semble le plus logique. Si vous faites cela, assurez-vous absolument que (1) tout le code de l'application passe par les couches avec la logique métier et (2) qu'il soit évident et / ou bien documenté où chaque règle de gestion a été implémentée. En cas de doute, n'essayez pas cela à la maison.

Note finale sur l'architecture de niveau entreprise

Si vous êtes dans une grande entreprise ou dans une autre situation où les mêmes tables de base de données sont partagées entre plusieurs applications, je vous recommande de laisser cette MyProjectpartie hors des espaces de noms / projets ci-dessus. De cette façon, ces couches peuvent être partagées par plusieurs applications frontales (ainsi que par des utilitaires en coulisse tels que Windows Services). Mais ne le faites que si vous avez une forte communication inter-équipes et des tests de régression automatisés complets en place !!! Sinon, les modifications apportées par une équipe à un composant central partagé risquent de briser l'application d'une autre équipe.

Je construis habituellement l'application en tant que

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

C'est un peu similaire à Sharp-Lite .

À propos des préfixes, je les déteste. Les directives de codage interne de Microsoft les détestent également. Il existe également un outil appelé StyleCop qui se plaint également des préfixes.