Ist der Root-Namespace in .net eine schlechte Idee?

Question

Ich habe ein Projekt über mehrere DLLs verteilt, hauptsächlich um die Dinge ein wenig organisierter zu halten und bei der Trennung zu bleiben. Ich habe erwogen, den Root-Namespace für alle Projekte auf dasselbe zu ändern, nur um die Dinge einfacher zu machen, aber dieser (alte) Artikel legt nahe, dass es keine übliche Praxis ist, gibt aber keinen Grund warum nicht.

Understanding and Using Assemblies and Namespaces

Es sei denn, Sie einen guten Grund für eine solche Anordnung haben, obwohl, ist es am besten Dinge einfach zu halten, mit einem Namensraum pro Baugruppe und umgekehrt.

Ist ein "guter Grund" in einem solchen Fall, wo Sie die Dinge in dieser Richtung organisieren möchten?

Projekt/Namespace

1. Core (interfaces)/CompanyName 
2. CommonServices/CompanyName.Services 
4. XYZProcess/CompanyName.XYZ 
5. XYZViews/ComapnyName.Views 
6. etc 

Answer 1

Der Hauptvorteil, denselben Namen für die Assembly wie für den Namespace zu haben, ist, wenn Ihr Projekt sehr groß wird und Sie oder ein anderer Ingenieur in Ihrem Team sich nicht daran erinnern, wo eine bestimmte Klasse lebt. Wenn Sie einfach über die Klasse fahren und den Namespace sehen, erhalten Sie einen Hinweis darauf, in welcher Assembly diese Klasse lebt. Dies ist jedoch keine feste Regel. Wenn Ihr Projekt klein genug ist, dass Sie sich immer daran erinnern, wo alles lebt, dann ist ein einzelner Namespace in Ordnung, und es gibt berechtigte Gründe, einen Namespace über Assemblys hinweg zu teilen.

Answer 2

In meiner Firma haben wir so etwas wie dieses:

• ProjectName.Core.Infrastructure
• ProjectName.Core.Services

Und diejenigen, sind Projektnamen. Meiner Meinung nach ist es besser, Projekt (in größerer Lösung) richtig zu benennen. Ist während des Entwicklungsprozesses einfacher zu navigieren.