Namespace e linee guida per i nomi delle classi


15

Ho problemi a nominare correttamente le mie classi e i miei servizi quando sono coinvolti utils e altre classi di aiuto.

Come struttureresti quanto segue:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

eccetera...

Ho più servizi con le stesse esigenze del servizio sopra. Un pensiero è quello di separare tutto questo in uno spazio dei nomi adatto, facendolo apparire così:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

e così via. Ogni spazio dei nomi è ovviamente una cartella separata. Ma questo non sembra al 100%, poiché probabilmente ce ne sono altri DateValidatorsnegli altri servizi, il che può facilmente portare a un riferimento indesiderato.

E Services.EventService.EventService.csinclude anche il nome della classe nello spazio dei nomi, che non va bene neanche. Potresti usare Services.Event.EventService.cs, ma ovviamente esiste già un'entità con quel nome.

Questo è il modello di dominio.


"Ho più servizi con le stesse esigenze del servizio precedente." Ciò significa che più servizi utilizzano il codice sopra riportato o che più servizi devono fornire la propria versione seguendo lo stesso schema?
Nathanael,

Che forniscono la propria versione dello stesso modello
Mattias,

Risposte:


5

Penso che la cosa più grande che potresti fare per migliorare il tuo spazio dei nomi qui sia rimuovere Servicedal tuo EventServicespazio dei nomi. Modificherei anche gli spazi dei nomi per essere più simili 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

Penso comunque che potrebbe essere utile qualche miglioramento.

Mi piacevano gli spazi dei nomi, ma al giorno d'oggi penso che meno sia di più. Annidare in profondità i tuoi spazi dei nomi può rendere il tuo codice troppo dettagliato, e la suddivisione delle cose riduce di molto la tua capacità di eredità. Nel tuo codice, ad esempio, una DateValidatorclasse potrebbe essere facilmente utilizzata altrove, quindi non dovrebbe avere molti spazi dei nomi al di sopra di essa, poiché i servizi diversi da EventService ora possono sfruttare una classe DateValidator. Lo stesso vale per i metodi di estensione. Non c'è tempo (che posso vedere) in cui avresti bisogno di vedere tutti i tuoi metodi di estensione allo stesso tempo, quindi ha più senso raggrupparlo con ciò a cui si riferisce. In questo caso, EventExtensionsprobabilmente i collegamenti ai tuoi EventService, quindi logicamente dovrebbero sedere insieme secondo me.


Il progetto è troppo grande per non ridurlo a un certo livello. DateValidator nello spazio dei nomi degli eventi gestisce solo casi specifici dell'evento e quindi non può essere utilizzato altrove. Mi piacciono i servizi. Eventi .EventService. Come potrei non pensarci. Penso che sia tempo di un po 'di refactoring!
Mattias,

@Mattias - È giusto. Per quanto posso vedere, lo spazio dei nomi (oltre le linee guida di base come quelle che Saeed ha menzionato di seguito) è praticamente solo una questione di gusti.
Karl Nicoll,


2

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

Sebbene la logica originale degli spazi dei nomi fosse principalmente quella di prevenire gli scontri tra nomi di oggetti e metodi, è diventata un elemento importante nell'architettura e nel design della soluzione generale. Non solo vuoi che la tua gerarchia concettuale e il tuo design logico abbiano un senso, ma probabilmente vuoi anche che il tuo codice sia impacchettato in modo ordinato in librerie ben progettate e facilmente riutilizzabili che possono essere facilmente raggruppate in altri progetti e prodotti in un secondo momento. Questo è forse il risultato desiderato di un buon design fisico.

Guarda .NET Framework e come ti vengono fornite unità di funzionalità correlate in assiemi di dimensioni ragionevoli. Puoi inserire un riferimento e un'istruzione using e improvvisamente hai a disposizione funzionalità pertinenti senza dover trascinare un numero qualsiasi di lavelli da cucina. Questo perché il design fisico di .NET Framework, incluso lo spazio dei nomi intelligente, ha impacchettato il codice logicamente correlato in unità distribuibili fisicamente correlate. 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 notevolmente più semplice (ovviamente alcuni potrebbero obiettare diversamente, ma sono piuttosto contento di quello che hanno fatto).

Lo spazio dei nomi in C # è piuttosto arbitrario, davvero. È possibile posizionare gli spazi dei nomi nei punti più strani, in assiemi lontani l'uno dall'altro. Qualsiasi disciplina utile in questo settore è davvero il tuo contributo personale a un prodotto software ben organizzato. Non oserei consigliarti esattamente cosa fare in ogni caso. Ciò che spero di ottenere, in questa risposta, è farti pensare al design fisico e al design logico quando definisci i tuoi spazi dei nomi. Più manterrai le cose logicamente correlate e distribuibili (fisicamente) in bundle, più facili saranno le cose in seguito, sia per te che per gli altri che potrebbero aver bisogno di gestire il tuo codice un giorno.

Quindi, ti preghiamo di pensare a come il tuo codice verrà impacchettato in assiemi e componenti quando risolvi i tuoi problemi di spazio dei nomi!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.