Normalerweise benenne ich nach Klassen im Business-Projekt als Manager.cs, wie BaseManager.cs, CommentsManager.cs, ProfileManager.cs, etc ...
Wie benennen Sie Ihre Klassen im DataAccess-Projekt? Nennen Sie es CommentsDA, CommentsDB oder was?
Nur neugierig ... BTW, ich benutze .NET C #.
Früher habe ich die Klassenbenennungskonventionen für jede Art von Softwareschicht getrennt, wie Sie es wünschen. In der .NET-Welt ist es jedoch bei der Realisierung jeder Ebene eine eigene Assembly, und Assemblies sind oft durch Assemblies, die dieselbe Schnittstelle implementieren, ersetzbar. Ich fand den Namespace als wichtigste / effektive Änderung und ließ kategoriespezifische Präfixe und Suffixe fallen. zum größten Teil.
Zum Beispiel hatte ich Customer (business) und CustomerDAL (Datenzugriffsschicht)
.. und das hat sich in meinen letzten Projekten oft geändert bzw. ...
Com.Example.ProjectName.Business.Customer und Com.Example.ProjectName.Data.Customer mit einer ICustomer Schnittstelle, die zwischen ihnen verwendet wird, anstatt direkt auf eine bestimmte Klasse im Zielprojekt zuzugreifen.
Normalerweise versuchen Sie durch die Implementierung eines Klassensuffixes oder -präfixes Konflikte gegen Konflikte zwischen eng verbundenen Einheiten zu vermeiden.
Es wird jedoch normalerweise empfohlen, lose gekoppelte Baugruppen über Schnittstellen zu verwenden. Ein Nebeneffekt ist, dass Sie den konkreten Klassennamen nicht mehr direkt verwenden. Sonst könnten Sie durch den Einsatz eng gekoppelter Assemblies diese zu einer Baugruppe zusammenfassen, da sie sich direkt aufeinander stützen und der Nutzen separater Baugruppen abnimmt.
Manchmal verwendet meine Software einen anschaulicheren Ansatz wie Kunde und CustomerData -Klassen, und mir ist klar, dass dies ein Suffix ist, aber die Absicht ist natürlicher Fluss und nicht zu Verhindern Sie Namenskonflikte, da sich meine Schnittstelle unabhängig davon zwischen ihnen befindet.
Kurz gesagt, macht die geringe Kohäsion die Frage unmöglich, welche Klassen in irgendeiner Schicht des Projekts zueinander benannt werden sollten / könnten. Und weil Sie bereits separate Geschäftseinheiten haben und Datenverantwortlichkeiten müssen Sie implizit wollen, dass eine geringe Kohäsion vorhanden ist. Also meine Antwort im Kontext des Anwendungsdesigns ist kein Klassensuffix oder Präfix ist objektiv besser nach dem Konzept der Frage.
Im Sinne eines nützlichen Codebeispiels schließe ich das folgende C # -Skelett ein, um die Klassenbenennungsrichtlinie zu zeigen, der ich mich hingezogen fühle (oder die fehlende Richtlinie könnte genauer sein).
Hinweis: Dieses Beispiel ist in mancher Hinsicht unvollständig, aber es zeigt das Konzept, wie Klassennamen zwischen Assemblys keine Rolle spielen (selbst wenn es sich um denselben Klassennamen handelt), da sie durch Schnittstellen getrennt sind.
Business.dll - Business-Schicht-Assembly
Referenz Shared.dll-Assembly.
%Vor%Business verwendet ICustomer, anstatt mit der Data.dll-Assembly fest verdrahtet zu sein.
Shared.dll - Geteilte Assembly - Auf allgemeine Datentypen wird sowohl in Business- als auch in Datenassemblys verwiesen.
%Vor%Data.dll - Datenzugriffsebene
Referenz Shared.dll-Assembly.
%Vor%Tags und Links class .net c# naming-conventions n-tier