Hai bisogno di aiuto con il piano di migrazione del sistema

4

Ho bisogno di riscrivere l'applicazione VB dei vecchi moduli web ASP.NET sul nuovo mvc di ASP.net in c #.

Il problema è che la maggior parte della vecchia logica applicativa per l'inserimento dei dati di recupero è scritta in stored procedure, che sono diventate disordinate nel tempo, poiché il vecchio team stava aggiungendo tonnellate di stored procedure, che stanno facendo la stessa cosa, ma contenevano piccole correzioni tempo, come FetchById1, FetchById1_fixed ecc.

Voglio allontanarmi da questo e utilizzare ORM come il framework di entità, ma il design del database non è molto amichevole con ORM. I dati sono sparsi, richiede molti join per interrogare i dati, il che renderebbe molto lenta la query EF, soprattutto perché l'applicazione è prevalentemente orientata alla lettura. Circa 50-60 persone inseriscono contemporaneamente articoli di notizie e il carico può arrivare a 10-30k utenti simultanei (secondo l'analisi in tempo reale).

Poiché il dominio principale si trova attorno alla tabella degli articoli e degli articoli di notizie, il mio piano è di aggiungere un trigger del database che attiverà la chiamata http a un piccolo servizio sul nostro server e identificherà l'ID dell'articolo appena creato o aggiornato. Il servizio conterrà tutta la logica necessaria per mappare i dati dal vecchio al nuovo database. (Il piano iniziale prevedeva l'utilizzo di una sorta di coda messaggi, ma non vogliamo toccare il codice legacy di un vecchio CMS).

In questo modo, ho intenzione di ottenere che tutto funzioni normalmente nel nostro sistema legacy, ma il nostro team può sviluppare applicazioni che saranno collegate a un nuovo database.

Sono sulla buona strada? Dovrei prendere in considerazione altri approcci?

    
posta Robert 17.02.2017 - 10:42
fonte

1 risposta

1

Non mi piace questo approccio perché non sembra affrontare il problema dichiarato. Risolve un problema diverso. La replica dei dati quasi in tempo reale dovrebbe essere necessaria solo se è necessario supportare l'accesso simultaneo, ovvero non è possibile ritirare la vecchia applicazione prima di avviarne una nuova.

Inoltre, questo:

Service will contain all necessary logic for mapping data from old to new database.

Se ritieni che ciò sia vero, allora non c'è ragione per cui non puoi eseguire esattamente la stessa logica sull'intero database.

La realtà è che probabilmente la tua migrazione avrà problemi. Se si esegue una migrazione "big bank", gli script di migrazione possono generare un "rapporto di fallout" di record che non superano la conversione. In alcuni casi è possibile regolare manualmente i dati di origine per far funzionare la conversione. In tal caso, il processo automatizzato non funzionerà: solo uno sforzo di conversione manuale, con report di fallback e miglioramenti iterativi, può fare il lavoro.

  1. Scrivi il miglior script di migrazione che puoi
  2. Esegui e genera rapporti di fallout
  3. Esaminare i report per tutti i pattern e, se possibile, migliorare gli script di migrazione
  4. Esamina i report per i problemi una tantum e correggi i dati di origine
  5. Ripeti i passaggi da 2 a 5 fino a quando i rapporti di fallout sono vuoti.
risposta data 21.02.2017 - 03:36
fonte

Leggi altre domande sui tag