Usare le classi parziali per supportare più versioni di entità di dati per scenari di consegna continua è una cattiva idea?

5

Se vuoi avere una consegna continua, qualsiasi schema di dati che hai deve supportare più versioni della tua applicazione contemporaneamente (dato che potresti aver implementato più versioni quando vengono lanciate nuove versioni)

Nel mio caso specifico ho entità archiviate nella memoria della tabella di Azure. Quando apporto modifiche alle mie entità, di solito devo aggiungere delle proprietà (poiché rimuoverle o rinominarle è una cattiva idea in quanto le versioni precedenti dell'applicazione potrebbero interrompersi), ma una volta che la nuova versione è stata completamente implementata non ho bisogno le vecchie versioni delle proprietà più come tutti i server là fuori stanno usando la nuova versione, il che significa che nel prossimo lancio posso rimuovere alcune delle vecchie proprietà.

Mi chiedo se questo problema possa essere risolto più facilmente avendo classi parziali per ogni versione dell'entità. Ciò garantisce che una versione sarà sempre cumulativa per una versione precedente (cioè non porterà mai via nulla o non cambierà nulla) ma consentirà la delega a una proprietà esistente se qualcosa deve semplicemente essere rinominata.

Una volta che la versione è stata completamente implementata e la vecchia versione non sarà mai necessaria, le classi parziali potrebbero essere di nuovo riunite in una singola classe (e rimuovere tutte le proprietà non necessarie). Se sai che avrai solo un paio di versioni 'live' in qualsiasi momento, potresti forse usare una versione 'corrente' e una versione 'vNext' in modo esplicito.

Non l'ho ancora provato come soluzione, ma mi chiedo se qualcun altro ha provato un approccio come questo e ha qualche feedback, o se qualcuno ha pensato se questa sia una buona o cattiva idea?

    
posta Sam Holder 24.05.2014 - 15:01
fonte

2 risposte

1

Le classi parziali sono solo un modo per suddividere una classe in più file. È particolarmente utile quando è possibile generare parti di una classe, ma anche il codice personalizzato. Non vedo come questo ti aiuti a selezionare quali proprietà sono obsolete per una nuova versione o meno.

Suggerirei di attribuire proprietà obsolete con [Obsolete("since version ...")] per tenere traccia delle proprietà che puoi rimuovere in un secondo momento.

È che puoi usare per separare vecchie e nuove API con entità diverse, e quelle possono trarre vantaggio dall'ereditarietà, per specificare chiaramente quali proprietà non esistevano nemmeno nel api più vecchie.

    
risposta data 24.04.2016 - 19:58
fonte
0

Non mi piace l'idea di classi parziali, la tua soluzione diventerà una Tomba.

Se si utilizza SQL, è possibile utilizzare SSDT (SQL Data Data Tools) e si avrà la possibilità di eseguire pre-script o post-script durante la distribuzione, leggere la versione corrente del server e dipende da questa versione alterare, aggiornare, eliminare ... E poi aggiorna la versione dopo che lo script è terminato con successo.

    
risposta data 01.04.2016 - 10:08
fonte

Leggi altre domande sui tag