Namespace e linee guida per il nome della classe

Penso che l'unica cosa che potresti fare per migliorare il tuo namespace qui è rimuovere Service dal tuo spazio dei nomi EventService . Regolerei anche gli spazi dei nomi per essere più simile a questo:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Continuo a pensare che potrebbe comunque migliorare.

Mi piacevano gli spazi dei nomi, ma oggi penso che meno sia di più. L'annidamento profondo dei tuoi spazi dei nomi può rendere il tuo codice troppo prolisso e rompere le cose fino a ridurre la tua capacità di ereditarietà. Nel tuo codice, ad esempio, una classe DateValidator potrebbe essere facilmente utilizzata altrove, quindi non dovrebbe avere molti spazi dei nomi sopra di essa, poiché servizi diversi da EventService possono ora usufruire di una classe DateValidator. Lo stesso vale per i metodi di estensione. Non c'è tempo (che io possa vedere) in cui dovresti vedere tutti i tuoi metodi di estensione allo stesso tempo, quindi ha più senso raggrupparlo con la cosa a cui si riferisce. In questo caso, EventExtensions probabilmente si collega al tuo EventService , quindi logicamente dovrebbero stare insieme a mio parere.

Perché non leggi Linee guida generali sui nomi e Norme per la denominazione dei nomi dello spazio di Microsoft per seguire un modello universale?

Penso che la formula <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>] funzioni correttamente.

La corretta progettazione dello spazio dei nomi prenderà in considerazione sia la progettazione logica che quella fisica.

Sebbene il razionale originale per gli spazi dei nomi fosse principalmente quello di evitare conflitti tra nomi di oggetti e metodi, è diventato un elemento importante nell'architettura e nella progettazione di soluzioni globali. Non solo vuoi che la tua gerarchia concettuale e la progettazione logica abbiano un senso, probabilmente vuoi anche che il tuo codice sia impacchettato in modo ordinato in librerie ben progettate e facilmente riusabili che possono essere facilmente raggruppate in altri progetti e prodotti successivamente. Questo è forse più il risultato desiderato di un buon design fisico.

Guarda .NET Framework e in che modo le unità di funzionalità correlate ti vengono fornite in assembly di dimensioni ragionevoli. È possibile inserire un riferimento e un'istruzione usando e all'improvviso sono disponibili funzionalità rilevanti senza dover trascinare alcun numero di lavelli da cucina. Ciò è dovuto al fatto che la progettazione fisica di .NET Framework, compreso il namespacing intelligente, include un codice logico correlato al pacchetto in unità distribuibili correlate fisicamente. Creando un'eccellente mappatura tra spazi dei nomi e assiemi, gli architetti e gli sviluppatori del framework .NET di Microsoft hanno reso il tuo lavoro molto più semplice (ovviamente alcuni potrebbero obiettare diversamente, ma sono piuttosto contento di ciò che hanno fatto).

Lo spazio dei nomi in C # è piuttosto arbitrario, davvero. È possibile inserire spazi dei nomi nei luoghi più strani, in assiemi molto distanti l'uno dall'altro. Qualsiasi disciplina utile in quest'area è davvero il tuo contributo personale a un prodotto software ben organizzato. Non oserei consigliarti su cosa fare esattamente in ogni caso. Ciò che spero di ottenere, in questa risposta, è di indurti a pensare al design fisico e al design logico quando definisci i tuoi spazi dei nomi. Più le cose vengono legate logicamente e distribuite (fisicamente) in modo distribuibile, più le cose saranno più semplici in seguito, sia per te che per gli altri che potrebbero aver bisogno di trattare il tuo codice un giorno.

Quindi, per favore, pensa a come verrà confezionato il tuo codice negli assembly e nei componenti quando risolvi i problemi del namespace!