Namenskonventionen DAL, BAL und UI Layer [closed]

Ich entwickle eine typische Webanwendung mit den folgenden Ebenen

1. Benutzeroberflächenebene (MVC)
2. Business Logic Layer (BAL)
3. Datenzugriffsschicht (DAL)

Jede Ebene verfügt über ein eigenes DTO-Objekt, einschließlich BAL und DAL. Meine diesbezüglichen Fragen lauten wie folgt

1. Das vom DAL zurückgegebene DTO wird einfach in das entsprechende DTO im BAL konvertiert und an die UI-Schicht gesendet. Beide Attribute und die Struktur der DTO-Objekte sind teilweise gleich. In solchen Szenarien ist es besser, das DTO in der DAL einfach an die UI-Schicht zurückzugeben, ohne ein Zwischenobjekt einzuschließen.

2. Wie können diese DTO-Objekte und andere Objekte in jeder Ebene am besten benannt werden? Soll ich ein Präfix wie DTOName oder ServiceName verwenden? Der Grund, warum ich nach einem Präfix frage, liegt darin, dass die Klassen in meiner Lösung nicht mit anderen Klassen im Framework kollidieren und es mir mit einem Präfix leichter fällt zu verstehen, wo jede Klasse hingehört.

Vorwort

Hoffentlich ist dies offensichtlich, aber ... in den unten vorgeschlagenen Namespaces würden Sie MyCompanyund MyProjectdurch die tatsächlichen Namen Ihrer Firma und Ihres Projekts ersetzen .

DTOs

Ich würde empfehlen, die gleichen DTO-Klassen auf allen Ebenen zu verwenden. Weniger Wartungspunkte auf diese Weise. Normalerweise setze ich sie MyCompany.MyProject.Modelsin ihrem eigenen VS-Projekt mit demselben Namen unter einen Namespace. Und ich benenne sie normalerweise einfach nach der realen Einheit, die sie repräsentieren. (Idealerweise verwenden die Datenbanktabellen auch dieselben Namen, aber manchmal ist es sinnvoll, das Schema dort etwas anders einzurichten.)

Beispiele: Person, Address,Product

Abhängigkeiten: Keine (außer Standard-.NET- oder Hilfsbibliotheken)

DAL

Ich persönlich bevorzuge hier die Verwendung einer Eins-zu-Eins-Gruppe von DAL-Klassen, die mit den DTO-Klassen übereinstimmen, jedoch in einem MyCompany.MyProject.DataAccessNamespace / Projekt. Klassennamen enden hier mit einem EngineSuffix, um Konflikte zu vermeiden. (Wenn Ihnen dieser Begriff nicht gefällt, kann auch ein DataAccessSuffix verwendet werden. Entsprechen Sie einfach Ihrer Auswahl.) Jede Klasse bietet einfache CRUD-Optionen für die Datenbank, wobei die DTO-Klassen für die meisten Eingabeparameter und Rückgabetypen (innerhalb) verwendet werden ein Generikum, Listwenn es mehr als ein Generikum gibt (z. B. die Rückgabe von einer Find()Methode).

Beispiele: PersonEngine, AddressEngine,ProductEngine

Abhängigkeiten: MyCompany.MyProject.Models

BAL / BLL

Auch hier eine Eins-zu-Eins-Zuordnung, jedoch in einem MyCompany.MyProject.LogicNamespace / Projekt, und mit Klassen, die ein LogicSuffix erhalten. Dies sollte die einzige Schicht sein, die den DAL aufruft! Klassen sind hier oft nur ein einfacher Durchgang zum DAL, aber wenn Geschäftsregeln implementiert werden müssen, ist dies der richtige Ort dafür.

Beispiele: PersonLogic, AddressLogic,ProductLogic

Abhängigkeiten: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

Wenn es eine Webservices-API-Schicht gibt, verwende ich denselben Eins-zu-Eins-Ansatz, jedoch in einem MyCompany.MyProject.WebApiNamespace / Projekt mit Servicesdem Klassensuffix. (Sofern Sie nicht die ASP.NET-Web-API verwenden, verwenden Sie in diesem Fall natürlich Controllerstattdessen das Suffix.)

Beispiele: PersonServices, AddressServices,ProductServices

Abhängigkeiten: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(nie Bypass dies durch die DAL direkt aufrufen!)

Eine Beobachtung zur Geschäftslogik

Es scheint immer häufiger zu sein, die BAL / BLL wegzulassen und stattdessen Geschäftslogik in einer oder mehreren der anderen Ebenen zu implementieren, wo immer dies am sinnvollsten ist. Wenn Sie dies tun, müssen Sie absolut sicher sein, dass (1) der gesamte Anwendungscode die Ebene (n) mit der Geschäftslogik durchläuft und (2) es offensichtlich und / oder gut dokumentiert ist, wo die einzelnen Geschäftsregeln implementiert wurden. Im Zweifelsfall versuchen Sie dies nicht zu Hause.

Ein letzter Hinweis zur Architektur auf Unternehmensebene

Wenn Sie sich in einem großen Unternehmen oder in einer anderen Situation befinden, in der dieselben Datenbanktabellen von mehreren Anwendungen gemeinsam genutzt werden, würde ich empfehlen, den MyProjectTeil aus den obigen Namespaces / Projekten herauszulassen. Auf diese Weise können diese Ebenen von mehreren Front-End-Anwendungen (und auch Hilfsprogrammen wie Windows Services) gemeinsam genutzt werden. Tun Sie dies jedoch nur, wenn Sie über eine starke teamübergreifende Kommunikation und gründliche automatisierte Regressionstests verfügen !!! Andernfalls können die Änderungen eines Teams an einer gemeinsam genutzten Kernkomponente die Anwendung eines anderen Teams beschädigen.

Normalerweise erstelle ich eine Anwendung als

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

Es ist Sharp-Lite etwas ähnlich .

Über Präfixe hasse ich sie. Die internen Codierungsrichtlinien von Microsoft hassen sie ebenfalls. Es gibt auch ein Tool namens StyleCop, das sich auch über Präfixe beschwert.