Come classi/metodi di applicazione .NET di livello intermedio versione

Question

Abbiamo una tipica applicazione N-Layer .NET che si trova tra il nostro database e il livello di servizio API Web. Questa applicazione è composta da Business Layer, Data Repository/Access e DTO e Business Objects correlati.

Abbiamo soluzioni per la versione delle procedure memorizzate e gli endpoint delle API Web. Il problema è la soluzione per la versione di questo livello intermedio, i metodi della classe e gli oggetti dello schema. Tutte le ricerche di Google forniscono risultati per il controllo del codice sorgente della versione in una soluzione di controllo del codice sorgente o la versione con le informazioni sull'assemblaggio, nessuno di questi è ciò a cui ci riferiamo, quindi i risultati sono limitati.

Così, per esempio, abbiamo due punti finali:

... api/v1/fiscali/oneri

... api/v2/fiscali/oneri

v1 deve colpire una versione di il metodo CalculateTaxPctgs e v2 raggiunge un'altra versione con logica aziendale aggiornata. Insieme a entrambi abbiamo bisogno di utilizzare diverse versioni di POCO Tax e TaxItems in quanto abbiamo cambiato il nome di un campo in v2.

La soluzione facile da sviluppare ma difficile da gestire e molto rigida/statica sarebbe quella di creare due metodi diversi, CalculateTaxPctgs_V1 e CalculateTaxPctgs_V2. Questa non sembra una buona idea.

Difficile trovare le migliori pratiche o anche soluzioni alternative per questo dilemma. Si tratta di un'applicazione aziendale che richiede milioni di richieste ogni giorno, pertanto le prestazioni sono estremamente importanti, così come la gestione e l'affidabilità del codice.

Answer 1

Ovviamente questo dipende esattamente come la vostra soluzione è mettere insieme, ma sarebbe riorientando le versioni di montaggio essere qualcosa che si potrebbe sfruttare:

https://msdn.microsoft.com/en-us/library/7wd6ex19%28v=vs.110%29.aspx

È possibile reindirizzare la vostra applicazione per utilizzare una versione diversa di un assembly in diversi modi: attraverso la politica dei publisher, attraverso un file di configurazione dell'app; o tramite il file di configurazione della macchina.

Answer 2

Invece di metodi diversi, utilizzerei l'ereditarietà degli oggetti. In questo modo se un metodo rimane lo stesso tra diverse versioni non è necessario modificare l'implementazione in alcun modo. Potresti quindi utilizzare una fabbrica di qualche tipo per creare l'istanza richiesta. Per esempio:

public virtual class TaxCalculatorBase { 
    public virtual ICollection<TaxPercentage> CalculateTaxPercentages() { 
     DefaultImplementation(); 
    } 
} 

public sealed class TaxCalculatorV1 : TaxCalculatorBase { 
    //Same implementation so no need to override 
} 

public sealed class TaxCalculatorV2 : TaxCalculatorBase { 
    //Same implementation but with a bit extra 
    public override ICollection<TaxPercentage> CalculateTaxPercentages() { 
     base.CalculateTaxPercentages(); 
     ExtraStuff(); 
    } 
} 

public sealed class TaxCalculatorV3 : TaxCalculatorBase { 
    //Different implementation 
    public override ICollection<TaxPercentage> CalculateTaxPercentages() { 
     NewImplementation(); 
    } 
} 

public static class TaxCalculatorFactory { 
    public static TaxCalculatorBase Create(int version) { 
     switch (version) { 
      case 1: return new TaxCalculatorV1; 
      case 2: return new TaxCalculatorV2; 
      case 3: return new TaxCalculatorV3; 
      default: throw new InvalidOperationException(); 
     } 
    } 
} 

public class CallingClass { 
    public void CallingMethod(int versionFromURL) { 
     var calculator = TaxCalculatorFactory.Create(versionFromURL); 
     var percentages = calculator.CalculateTaxPercentages(); 
     percentages.DoStuffWithThem(); 
    } 
} 

Se l'API implementa un'intera nuova versione ogni volta che la fabbrica può essere più generico e qualcosa di simile:

public static class MyFactory { 
    public static TaxCalculatorBase CreateTaxCalculator(int version) { 
      switch (version) { 
       case 1: return new TaxCalculatorV1; 
       case 2: return new TaxCalculatorV2; 
       case 3: return new TaxCalculatorV3; 
       default: throw new InvalidOperationException(); 
      } 
     } 
    } 
    //various other methods to create classes which depend on version 
} 

Answer 3

per risolvere questo problema abbiamo implementato in modo dinamico il caricamento di assemblee che gestisce oltre 80 diverse versioni. Funziona bene. Non cambiamo il software distribuito (a meno che non ci sia un grave difetto) poiché fa parte di un sistema di produzione che non possiamo permetterci di interrompere una volta che funziona.

Abbiamo anche alcune modifiche critiche nel tempo, come l'utilizzo di diverse versioni di .NET. Per gestirlo, instradiamo le richieste a diverse distribuzioni di applicazioni.