Ich habe kürzlich eine mittelgroße Anwendung umstrukturiert und eine der Aufgaben bestand darin, häufig verwendeten Code in verschiedene Projekte aufzuteilen.Bevorzugte Namespace-Namenskonvention
kann nun sagen, dass häufig verwendete Namespace-Struktur
Core.Interfaces ist - für die Hauptanwendung mit einer Schnittstelle von IFoo
und für jedes Fach/extern/referenzierte Assembly habe ich beschlossen, eine Erweiterung zu machen dass, wie
Core.Interfaces.Html mit einer Schnittstelle von IBar
Die Assembly Core der Hauptanwendung befindet sich in einem Projekt namens Core mit einem Standardnamespace von Core während für die Html Assembly ich ein Projekt mit dem Namen HtmlCore mit einem Standardnamespace von Core erstellt.
Das Ergebnis Wirkung (und der Grund, warum ich diese besondere Methodik ausgewählt) ist, dass, sobald Sie die Html Assembly verwiesen haben die using Aussagen nicht aktualisiert werden müssen und der Nettoeffekt ist
Core.Interfaces.IFoo fooIf;
Core.Interfaces.Html.IBar barIf;
oder mit einem Verwendung der Anweisung Core.Interfaces die oben transformiert
IFoo fooIf;
Html.IBar barIf;
Diese impliziten Namensraum-Struktur ist eine direkte Folge der Abhängigkeiten und es hat uns wirklich gut gedient, da es die Wartung des Projekt-Namespaces erleichtert und das einzige, was jemand haben muss, der Verweis auf die Assembly ist. Die Struktur ähnelt der, die Microsoft bereits für das .NET-Framework verwendet.
Die Sache ist, dass ich Bedenken haben und (für zukünftige Projekte) i einen Namespace-Struktur am überlegen, die für jede Versammlung wie explizit:
Core.DataInterfaces
Html.Core.DataInterfaces
So hat sich mit der explizite Struktur jemand gearbeitet , beides oder sogar etwas anderes, das ich nicht versucht habe? Ich bin offen für Vorschläge und ich suche nach der besten Lösung, da das Ziel darin besteht, während der Entwicklung Zeit für Wartung und Verwirrung im Team freizumachen.