Qual è il modo più efficace per condividere il codice tra le applicazioni .NET?

12

Nel nostro lavoro, abbiamo diverse applicazioni .NET che condividono molte funzionalità di base. Abbiamo creato queste applicazioni utilizzando un'architettura pulita a più livelli, ma abbiamo colto il momento in cui ci rendiamo conto che abbiamo implementato nuovamente le stesse funzioni diverse volte. Ovviamente questo viola DRY e vorremmo correggerlo. Stiamo già utilizzando Nuget con un certo successo per il codice comune della colla (cablaggio di IoC, registrazione, impostazioni), ma vorremmo anche condividere i nostri dati e livelli aziendali tra tutte le nostre applicazioni. L'idea è che l'interfaccia utente si occupi solo delle parti del livello aziendale di cui ha effettivamente bisogno.

All'inizio questo sembra un problema immediato, ma lo sviluppo in corso potrebbe fornire alcune insidie e non siamo sicuri su come procedere. Diciamo che facciamo il nostro One Business Layer per dominarli tutti. Per brevità, lo chiamerò "Fondazione". Portiamo le nostre applicazioni per usare la Fondazione e tutto funziona alla grande. La Fondazione è distribuita per illuminare i livelli dell'interfaccia utente tramite nuget e stiamo andando bene. Ma poi iniziamo ad aggiungere funzionalità alle nostre applicazioni e ci imbattiamo in problemi.

Diciamo che stiamo lavorando al Progetto A e aggiungiamo una nuova funzionalità che richiede modifiche a Foundation. Apportiamo le modifiche alla fondazione (Foundation-A) e le inviamo al feed di nuget come pacchetto instabile. Il progetto A ottiene l'ultimo pacchetto di nuget e tutto va bene. Nel frattempo, un altro sviluppatore sta lavorando al Progetto B. Ottiene l'ultima base dal controllo del codice sorgente, ma la prende da un ramo stabile, in modo che non abbia modifiche al Progetto A. Apporta modifiche e crea Foundation-B. E tutto va bene. Ma poi scopriamo che le funzionalità di implementazione di Foundation-A e Foundation-B che potrebbero effettivamente condividere il codice, quindi le combiniamo. Nel frattempo, la Fondazione C sta fluttuando là fuori con le sue stesse modifiche. Alla fine, Foundation-B è pronto per la produzione, quindi lo spingiamo fuori. Ma poi dobbiamo aggiornare la produzione A, B, & C con le nuove fondamenta, quindi aggiorniamo i pacchetti di nuget e lo distribuiamo (finché non si interrompe nulla).

Sembra che potrebbe funzionare, ma siamo preoccupati di lavorare con diversi schemi di database e di mantenere tutto sincronizzato tra i vari rami del repository di Foundation così come i repository Project A, B e C. Sembra che probabilmente richiederà molto lavoro manuale, il che apre la possibilità di errori. Mi piacerebbe che fosse il più automatico possibile.

Ecco lo stack che stiamo utilizzando: C #, TFS con integrazione continua, Nuget. Le nostre applicazioni sono tutti i vari tipi di applicazioni ASP.NET. Siamo disposti a guardare diversi SCM se renderà le cose più facili.

Sto cercando modi per mantenere Nuget sano con i nostri diversi rami del codice sorgente. Non vogliamo inserire accidentalmente il codice di sviluppo in produzione perché facciamo riferimento al pacchetto Nuget sbagliato.

    
posta Josh 02.10.2013 - 04:54
fonte

5 risposte

7

We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package.

Ecco dove inizia il tuo problema ... Non farlo.

Eventuali modifiche a Foundation v1.0 dovrebbero essere intrinsecamente valide per tutti i consumatori di Foundation, altrimenti non appartengono a Foundation. Quindi, quando crei il pacchetto nuget, fallo come versione ufficiale e stabile di Foundation (ad esempio v1.1), oppure non farlo affatto.

Il Progetto B dovrebbe costruire i suoi miglioramenti alla Fondazione come normalmente farebbe, ma (in una buona gestione della sorgente) dovrebbe unire le modifiche del tronco (v1.1) prima di spingere una fondazione stabile (v1.2) in nuget.

Gli altri progetti che possono utilizzare i miglioramenti di Foundation possono aggiornare i loro riferimenti a nuget, se necessario, oppure attenersi alle versioni precedenti se necessario.

Sono d'accordo con @Giedrius ; questo mi sembra più un problema di controllo / ramificazione di origine nel senso che se la ramificazione / fusione di Foundation viene gestita correttamente, i problemi di gestione dei pacchetti diventano discutibili.

    
risposta data 02.10.2013 - 17:15
fonte
4

Rifatta il tuo codice duplicato in funzioni che sono applicabili in un modo più astratto e inseriscile nelle loro librerie o strutture. Rendili estesamente accoppiati e indipendenti dall'architettura e non dovresti avere alcun problema. Se hai bisogno di ispirazione, studia come il framework .NET astrae i concetti usando cose come interfacce, generici e pattern software come Dispose() .

Inoltre, ricorda che non tutto il codice duplicato è realmente duplicato; alcuni di essi sono codice di colla o codice che è altrimenti necessario per sostenere l'architettura, quindi non essere ossessionati dall'essere troppo ASCIUTTI.

    
risposta data 02.10.2013 - 06:02
fonte
4

Riutilizzo del codice

Ci sono stati diversi approcci al riutilizzo del codice che hanno trovato il favore negli anni. Ogni approccio ha il suo posto, e soprattutto i suoi problemi , ma i modi percorribili per riutilizzare il codice in .NET sono:

  1. Libreria comune. Il codice necessario in più di una posizione viene inserito in una libreria comune e tutte le altre parti della base di codice hanno un unico riferimento a questo codice. Lo svantaggio principale è che si finisce con la maggior parte del progetto a seconda di questa libreria che contiene molte funzioni non correlate. Questa è una cattiva idea da un aspetto di garanzia della qualità.

  2. Common Source Code. Il codice necessario in più di una posizione viene scritto una volta e inserito in un file di origine in una struttura di directory comune. Tutti i progetti che richiedono questo codice quindi includono questo file come uno dei loro file sorgente. Ciò fornisce il riutilizzo del codice e i vantaggi di scrivere una sola volta, utilizzare molti. Però. Il suo svantaggio è che diventa possibile avere diverse parti del progetto compilate con versioni diverse di questo codice, che possono introdurre alcuni difetti sottili che possono essere molto difficili da individuare e identificare con la garanzia della qualità.

  3. Servizio. Il codice comune è implementato come un servizio, a cui altri aspetti possono accedere. Questo ha il vantaggio che ci sarà un singolo servizio in una distribuzione ed eviterà le dipendenze. Comunque introdurrà latenza e fallimenti. Questo tipo di approccio funziona bene in prodotti distribuiti di grandi dimensioni in cui l'alta disponibilità e la tolleranza agli errori sono già compresi e gestiti.

Gestione di NuGET

Qui hai un problema molto più interessante. Gestione di più configurazioni. Il mio consiglio qui è di non gestire una clientela diversificata con versioni di codice diverse, ma con file di configurazione. Ci sono almeno 3 livelli di dati di configurazione da gestire. Configurazione di base (interna) del prodotto che il cliente non vede mai. Le opzioni di configurazione predefinite che il cliente può modificare e il livello finale delle opzioni di configurazione modificate dal cliente. Separando questi diversi livelli sarai in grado di implementare gli aggiornamenti senza distruggere le configurazioni dei tuoi clienti.

    
risposta data 02.10.2013 - 17:28
fonte
1

Penso che il problema non sia in nuget / source control / branching, ma in cosa scivola nel codice di incollaggio.

Robert ha una bella risposta, solo per vedere l'intera immagine, consiglio di pensare a quali dipendenze queste utilità comuni porteranno in ogni progetto:

link link

Il modo migliore per evitare l'inferno che stai avendo è di aprire il codice della tua colla. In questo modo inizierai a preoccuparti, che nessuna logica di business diventerebbe pubblica, quindi nessuna dipendenza concreta dal progetto scivolerà nel codice della colla, che sarebbe abbastanza astratta da essere riutilizzata da chiunque, anche al di fuori della tua azienda - e se questo si incolla il codice sarà abbastanza buono - riceverai anche l'input della community.

    
risposta data 02.10.2013 - 11:24
fonte
-1

La soluzione è semplice: crea un progetto separato per esso e gestiscilo come cosa separata: le sue esigenze, test, convenzioni, documentazione, pianificazione, persone, ecc. In questo modo, assicuri che la qualità rimanga elevata e possibile rottura le modifiche verranno valutate prima di creare un problema.

O ancora meglio: rendilo "open-source" all'interno della tua organizzazione. Quindi chiunque può modificare il codice, ma solo poche persone selezionate avranno diritti di commit completi. E quelle persone saranno responsabili di garantire la qualità e le funzionalità corrette.

    
risposta data 02.10.2013 - 16:56
fonte

Leggi altre domande sui tag