Miglior approccio per la libreria di classi di utilità utilizzando Visual Studio

2

Ho una collezione di classi che uso comunemente (ma non sempre) durante lo sviluppo di applicazioni WPF. Il problema che ho è che se voglio usare solo un sottoinsieme delle classi, ho tre opzioni:

  1. Distribuisci l'intera DLL. Sebbene questo approccio semplifica la manutenzione del codice, richiede la distribuzione di una DLL di grandi dimensioni per la minima funzionalità del codice.
  2. Copia le classi che ho bisogno dell'applicazione corrente. Questo approccio risolve il problema di non distribuire il codice inutilizzato, ma elimina completamente la manutenzione del codice.
  3. Mantieni ogni classe / funzione in un progetto separato. Questo risolve entrambi i problemi dall'alto, ma poi ho drasticamente aumentato il numero di file che devono essere distribuiti, e gonfia la mia soluzione VS con piccoli progetti.

Idealmente, mi piacerebbe una combinazione di 1 & 3: Un singolo progetto che contiene tutte le mie classi di utilità ma crea una DLL contenente solo le classi utilizzate nell'applicazione corrente.

Ci sono altri approcci comuni che non ho considerato? C'è un modo per fare ciò che voglio?

Grazie.

    
posta gregsdennis 31.08.2012 - 14:17
fonte

2 risposte

4

Il modo in cui l'ho fatto in passato (su altri sistemi) sta usando un repository. I file comuni sono tutti in una parte della libreria del repository, ma ogni soluzione li mappa su un singolo progetto.

In questo modo, tutte le soluzioni utilizzano tutte lo stesso codice sorgente, ma ciascuna soluzione utilizza solo i file necessari.

Questo post sul blog di MS ti dice come farlo (per VS2005).

Nota che se lo fai, devi assicurarti che tutte le funzionalità comuni siano completamente coperte dai test unitari. Altrimenti, cambiando la funzionalità di uno di questi file comuni in un modo in cui solo una delle esigenze di soluzioni incluse potrebbe rompere più soluzioni.

    
risposta data 31.08.2012 - 14:29
fonte
2

L'approccio che voglio prendere ora è quello di utilizzare pacchetti (Nuget o openwrap) per il mio codice di utilità condivisa e quindi di inserirli nei progetti secondo necessità utilizzando un server privato.

Le librerie stesse verrebbero quindi sviluppate indipendentemente dai progetti che servono, il che dovrebbe farti uscire da un sacco di problemi VCS. Essendo la tua libarary puoi suddividere i pezzi in altrettanti pacchetti di nuget come appropriato / desiderabile (e questo include la possibilità di avere meta pacchetti che inseriscono diversi componenti discreti).

Per inciso, non sono sicuro che sarei eccessivamente preoccupato del codice gonfiato nell'istanza generale - capisco perché (storicamente è stato un problema di tanto in tanto) ma al momento siamo in un punto in cui la capacità di memorizzazione dei dati e le velocità di trasferimento dei dati sono elevate rispetto alle dimensioni del codice distribuito. (E per essere chiari, "non eccessivamente preoccupati" non significa che non mi interessi, solo che probabilmente non è una priorità.)

    
risposta data 31.08.2012 - 17:56
fonte

Leggi altre domande sui tag