Livelli: separazione logica vs fisica

6

Alcuni programmatori consigliano la separazione logica dei livelli su fisico. Ad esempio, dato un DL, questo significa che creiamo uno spazio dei nomi DL non un assembly DL.

I vantaggi includono:

  1. tempo di compilazione più veloce
  2. implementazione più semplice
  3. Tempo di avvio più rapido per il tuo programma
  4. Meno assiemi per fare riferimento a

Sono in una piccola squadra di 5 sviluppatori. Abbiamo oltre 50 assembly da mantenere. IMO questo rapporto è lontano dall'ideale. Preferisco un approccio di programmazione estremo. Dove se 100 assembly sono più facili da gestire rispetto a 10.000 ... allora 1 assembly deve essere più semplice di 100. Dati i limiti tecnici, dovremmo sforzarci di < 5 assemblaggi. I nuovi assembly vengono creati per esigenze tecniche e non per requisiti di livello.

Gli sviluppatori sono preoccupati per alcuni motivi.

A. Alle persone piace lavorare nel proprio ambiente in modo da non calpestare le dita dei piedi.

B. Microsoft tende a creare nuovi assembly. PER ESEMPIO. Asp.net ha la sua DLL, così fa winforms. Ecc.

C. Gli sviluppatori visualizzano questa unità per un assembly comune come una minaccia. Alcuni membri del team hanno la tendenza a cambiare il livello comune senza considerare il modo in cui influirà sulle dipendenze.

La mia opinione personale:

Visualizzo A. come silos, ovvero programmazione cowboy e suggeriamo di implementare la ramificazione per creare l'isolamento. C. In primo luogo, questo è un problema umano e non dovremmo creare soluzioni tecniche per il comportamento umano. In secondo luogo, il mio obiettivo non è quello di mettere tutto in comune. Piuttosto, voglio che le partizioni siano fatte in namespace e non in assembly. Avere un assembly condiviso non rende tutto comune.

Voglio che la comunità intervenga e mi dica se ho perso il rocker. L'unità di una singola assemblea o il mio punto di vista sono illogici o comunque una cattiva idea?

    
posta P.Brian.Mackey 20.04.2012 - 14:37
fonte

4 risposte

4

Nell'ecosistema .NET l'esistenza di molti assembly è dovuta alla convinzione che un assembly cs / vb / fsproj == assembly. In aggiunta a ciò, le pratiche che MS sta facendo da anni per avere un cs / vb / fsproj per ogni "livello" (lo uso nelle citazioni perché hanno spinto sia i livelli che i livelli in momenti diversi) e si finisce con le soluzioni che contengono dozzine e persino centinaia di file di progetto e, in ultima analisi, assemblaggi.

Sono fermamente convinto che Visual Studio, o qualsiasi IDE, sia non il luogo in cui dovresti essere architettato l'output dell'assembly del tuo progetto. Chiamalo Separazione delle preoccupazioni se vuoi; Credo che scrivere codice e assemblare codice siano due preoccupazioni diverse. Ciò mi porta al punto in cui i progetti / soluzioni che vedo nel mio IDE dovrebbero essere organizzati e strutturati in modo da consentire al team di sviluppo di scrivere il codice al meglio. Il mio script di compilazione è la posizione in cui i team di sviluppo / architettura si concentrano su come assemblare il codice raw in risorse compilate e, in definitiva, su come implementarli in posizioni fisiche diverse. È prudente notare che io assolutamente uso non MSBuild e che è strettamente accoppiato a * strutture di file proj per i miei script di compilazione. MSBuild, ed è strettamente inerente ai file * proj e alle loro strutture, non ci consente alcuna flessibilità nel passare dal problema dei grandi conteggi di progetti e assemblaggi nelle basi di codice. Invece utilizzo altri strumenti e fornisco i file necessari direttamente al compilatore (csc.exe, vbc.exe, ecc.).

Prendendo questa posizione sono in grado di concentrare il mio team di sviluppo sulla funzionalità di scrittura senza pensare agli assembly che verranno generati. Qualcuno, sicuramente, dirà "Ma ciò significa che gli sviluppatori possono inserire il codice negli assembly in cui non dovrebbe essere inserito". Solo perché il codice dovrebbe essere compilato nell'IDE non significa che sarebbe quando si esegue lo script di compilazione ... e, in definitiva, lo script di compilazione è l'unica fonte di verità per come verranno costruiti gli assembly. Il fatto è che, per fare ciò, probabilmente dovresti modificare lo script di compilazione per inserire quel codice nella posizione indesiderata. Una tecnica che uso per eseguire il backup di questo è creare test unitari che descrivono e verificano l'architettura e gli elementi utilizzabili nel progetto. Se le classi nei livelli dell'interfaccia utente non dovrebbero mai fare riferimento a quelle nel livello di accesso ai dati, allora scrivo un test che lo impone. Quei tipi di test dovranno essere cambiati se decidiamo di cambiare i deployables o l'architettura, ma dal momento che raddoppieranno anche come documentazione su questi argomenti, dovremmo cambiarli per assicurarci che la documentazione sia aggiornata.

Il rovescio della medaglia di questo argomento è il fatto che cambiare gli assembly e gli oggetti utilizzabili diventa molto più semplice e veloce. Invece di dover spostare il codice e i file da un file * proj a un altro e incorrere in tutti i problemi che molti sistemi di controllo delle versioni hanno con quell'attività, tutto ciò che devi fare è rielaborare lo script di compilazione per l'origine dei contenuti di ogni assembly dal già esistente posizioni fisiche. È questa capacità che mette in evidenza il disaccoppiamento tra il modo in cui strutturiamo la nostra soluzione e i file * proj e come creiamo i nostri assembly di output. Con questa tecnica, siamo in grado di regolare sia il numero che il contenuto degli assembly che creiamo senza dover mai regolare il modo in cui il codice è strutturato nell'IDE. Non solo abbiamo la flessibilità di cambiare i nostri output regolarmente e facilmente, ma quando lo facciamo gli sviluppatori non sono influenzati dal dover scoprire dove si sono trasferiti i file. Il sovraccarico di re-learning dei cambiamenti è inesistente.

L'unico inconveniente che molte persone incontrano quando si osserva questo tipo di soluzione è che non si può più essere in grado di "Hit F5" per eseguire l'applicazione. Mentre direi che non vuoi farlo comunque, deve essere affrontato. Le soluzioni sono disponibili e variano a seconda del tipo di applicazione che stai creando. L'unica somiglianza tra loro è che se devi assolutamente passare attraverso il codice per eseguire il debug / testarlo, scopri come allegare al processo.

Per riassumere, usa l'IDE per lo sviluppo del codice. Utilizzare una soluzione di creazione script che non dipenda dalla soluzione definita e dalle strutture * proj per progettare e creare le implementabili di cui l'applicazione ha bisogno. Mantieni separate queste due attività e vedrai molto meno attrito a causa dei cambiamenti del livello di implementazione.

    
risposta data 20.04.2012 - 17:39
fonte
1

Qui è davvero una buona guida per quali ragioni dovresti dividere i programmi .NET negli assembly e per quali motivi non dovresti farlo In relazione alla tua domanda, il documento dice che A dovrebbe essere gestito dal tuo SCCS, la logica alla base di B potrebbe essere la visibilità per cui non devi preoccuparti finché non sei un fornitore di framework e C può essere gestito da uno strumento come NDepend.

Naturalmente, questo è raccomandato dai produttori di NDepend, che è uno strumento commerciale, e il controllo delle dipendenze cicliche tra diversi livelli logici in un assembly è possibile solo con uno strumento come NDepend. Quindi, ciò che suggeriscono ha molto senso se acquisti il loro strumento (tuttavia la maggior parte degli argomenti nel documento mi sembra ragionevole).

    
risposta data 20.04.2012 - 15:15
fonte
0

In linea di principio, sostengo il tuo desiderio di un minor numero di assemblee. Avere più assiemi richiede una giustificazione tecnica, mentre avere pochi assiemi ha la semplicità da parte sua e non ha bisogno di altre giustificazioni.

In generale, la separazione logica è più strong e più pulita della separazione fisica. Il confine tra gli assiemi è un ostacolo tecnico molto piccolo per il bug e il codice rot. Il confine più potente è il confine sociale ("questa è la biblioteca di Tom, non ci fottocherò"), e gli spazi dei nomi offrono la stessa sicurezza.

Tieni presente, tuttavia, che sono i motivi tecnici per gli assembly separati, anche se tutti i vantaggi sono nel sito di distribuzione e consumer.

    
risposta data 20.04.2012 - 14:49
fonte
0

Nell'infanzia di un progetto, ha senso separare i moduli in assiemi distinti perché ci sarà molto flusso e grazie al formato del progetto di Visual Studio, l'aggiunta di nuovi file cambia il file di progetto in un modo che rende talvolta difficile l'unione. Confronta con rake o nant dove usi i caratteri jolly per determinare quali file includere nella compilation.

Per questo motivo, preferisco iniziare con assembly fisici separati e unirli insieme mentre i moduli diventano più stabili. In questo modo ottieni il meglio da entrambi i mondi ... meno collisioni di fusione all'inizio e una migliore compilazione / avvio iniziale mentre marcia verso il rilascio.

    
risposta data 20.04.2012 - 17:14
fonte

Leggi altre domande sui tag