Bucketing di classe. .
https://stackoverflow.com/questions/312565
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Ok, quindi ho provato a mettere tutti i miei corsi in una cartella radice, o:
UI
BusinessLogic
DataAccess
BusinessObjects
Interfacce
Ne ho alcuni in più in cui non riesco a benissimo, quindi sto cercando suggerimenti
-
Una classe di cache che mantiene un dizionario privato e consente un diverso accesso agli oggetti basato su alcune chiavi specifiche
-
Classi Event Arg?
Inoltre, nell'ambito di un progetto ora inizio ad avere sottosistemi che hanno tutti e 3 (accesso ai dati, oggetti business, busiensslogic). Come dovrei spezzare la struttura delle cartelle?
A.
ProjectX
--Subsystem1
---- BusinessObjects
---- DataAccess
---- BusinessObjects
--Subsystem2
---- BusinessObjects
---- DataAccess
---- BusinessObjects
o
ProjectX
--BusienssLogic
---- Subsystem1BL
---- Subsystem2BL
--DataAccess
---- Subsystem1DA
---- Subsystem2DA
--BusinessObjects
---- Subsystem1BO
---- Sottosistema2BO
o
ProjectX
--BusinessLogic
--DataAccess
--BusinessObjects
(senza sottodirectory per ciascun sottosistema funzionale)
Soluzione
Provo ad allineare i nomi dei miei assembly con i loro spazi dei nomi e utilizzo .NET Framework stesso come linea guida. Sono fermamente convinto che lavorare con una struttura dello spazio dei nomi che guida una struttura di cartelle rende una base di codice molto più gestibile.
Ad esempio, ho un provider di cache che fa parte del framework di sviluppo globale che utilizziamo. Vive in uno spazio dei nomi di qualcosa di simile a:
[società] .Core.Data.Caching
Ho altre funzionalità relative ai dati che logicamente ricadono sotto la funzione Dati, quindi la memorizzazione nella cache ha fratelli come adattatori, convertitori e generatori. Supponiamo quindi che abbiamo i seguenti spazi dei nomi:
[società] .Core.Data.Adapters
[Azienda] .Core.Data.Converters
[Azienda] .Core.Data.Caching
[Azienda] .Core.Data.Generators
Questi spazi dei nomi correlati vivono in un assembly chiamato [Company] .Core.Data, che è anche il nome del progetto. Trovare cose nella soluzione diventa molto semplice seguendo questa struttura. A proposito di struttura, torniamo ora al modo in cui sono memorizzati su disco.
Il nome del progetto è il nome della cartella principale. Questo presuppone la mia cartella di controllo del codice sorgente, che è " C: \ Controllo del codice sorgente " sul mio computer locale:
C: \ Source Control \ Core [Company] .Core.Data \
C: \ Source Control \ Core [Azienda] .Core.Data \ Adapters
C: \ Source Control \ Core [Azienda] .Core.Data \ Caching
C: \ Controllo sorgente \ Core [Azienda] .Core.Data \ Convertitori
C: \ Source Control \ Core [Azienda] .Core.Data \ Generators
Quindi, come gerarchia, sembra qualcosa del genere:
[Soluzione]
- [Azienda] .Core.Data
---- [adattatori]
------ (file degli adattatori)
---- [Caching]
------ (file di cache)
---- [Converters]
------ (file dei convertitori)
Metto tutti i progetti allo stesso livello e vari spazi secondari con le cartelle. In questo modo gli spazi dei nomi e le strutture fisiche sono facili da riconciliare. La parte difficile è trovare equilibrio. Non si desidera disporre di un numero elevato di assiemi più piccoli, quindi normalmente li raggrupperò a un livello superiore e alla fine lo rifletterò quando o tende a diventare troppo grande o se gli spazi dei nomi secondari cambiano più frequentemente rispetto ad altre parti .
Lo faccio da anni ormai, ed è molto comodo non solo per me stesso, ma anche per i miei sviluppatori.
Per quanto riguarda la tua domanda su EventArgs, concordo con il consenso sul fatto che normalmente eseguo una classe per file, ma farò l'eccezione per posizionare una classe EventArgs con un'altra classe se si tratta di un uso singolare. Per multiuso, li ho posizionati nel punto logico più alto nell'assieme, consentendo alla struttura dello spazio dei nomi di legare il mio ambito.
Altri suggerimenti
Di solito mi piace attenermi alla regola di 1 classe, 1 file, ma quando si tratta di EventArgs, in realtà mi piace dichiararli nello stesso file che definisco il delegato o l'evento. A meno che, gli arg non siano usati da più di una gerarchia di classi, cosa che non mi capita spesso di capitare.
Per quanto riguarda la cache, vorrei inserire la cartella delle classi in cui supporta.
Per quanto mi piaccia la buona organizzazione, si può diventare troppo anali con esso.
Questo è principalmente gusto personale.
Sono d'accordo con ciò che Brian Genisio ha detto riguardo a dove mettere le classi EventArg ecc .: se solo tu usali una volta, inseriscili nello stesso file in cui li usi. Per le classi / i file generali, ho sempre una cartella "Generale" (quanto conveniente! ;-))
Per quanto riguarda la struttura delle cartelle: andrei con il secondo, quello a 3 livelli E mantiene separati i sottosistemi. Win-Win!
Voglio solo aggiungere un commento sui nomi. Sento che la parola business porta a un uso improprio. Lo abbiamo fatto e ora non sappiamo di cosa si tratta: logica di dominio o livello di servizio. Vorrei suggerire nomi come Dominio. Domain.Impl (per separare le interfacce da Impl) e quindi Servizi ... e forse Persistenza se si utilizza ORM ... potrebbe essere diverso se si utilizza un approccio diverso, ma ad essere sincero, sono confuso sui nomi BusinessLogic, DataAccess e BusinessObjects. Non capisco cosa sia cosa. BusinessObjects dovrebbe contenere una logica aziendale, logica? O sono solo DTO? Allora perché si trovano in un progetto separato da DataAccess?
