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.