Strategie per la sostituzione di oggetti sistemici

Question

Attualmente stiamo intraprendendo la sostituzione dello stack ADO.NET nella nostra applicazione C# con Linq.

Poiché l'applicazione non è stata progettata con un livello di astrazione dati, ci sono chiamate ADO in quasi tutti i livelli dell'applicazione a un grado tale che compartimentare un oggetto e provare a convertirlo in Linq significa che si esegue un labirinto di buchi di coniglio.

Quello che sto chiedendo, sono le strategie o gli approcci per affrontare tali cambiamenti sistemici all'ingrosso, garantendo al tempo stesso test adeguati e un periodo minimo di abbattimento degli strumenti di rilascio (la shelf-making cambia in un attimo e torna in un secondo momento Data).

Abbiamo giocato con il seguente:

• Creare un oggetto specchio di ogni oggetto con il nuovo codice = hanno a mantenere 2 basi di codice fino a conversione completa
• prefisso di tutte le funzioni di funzioni ADO con ADO_ e creare versioni Linq con nome originale
• Avere un FLAG di sistema per indicare se utilizzare ADO o Linq e avvolgere ogni chiamata ADO con if (FLAG) {ADO} else {Linq} = deve tornare dopo la conversione e rimuovere tutto Rif. ADO

Ogni suggerimento fino ad ora è meritevole.

Che cosa suggerite voi ragazzi/ragazze?

NOTA: Ho rimosso "(ADO to Link)" dal titolo perché sto cercando risposte e pratiche più generiche e non solo limitato alla conversione da ADO a Linq utilizzata come esempio qui.

Answer 1

È necessario disporre di test dell'unità automatizzati prima di apportare qualsiasi modifica. Di fatto, non dovresti apportare modifiche per il codice che non è coperto dai test unitari di almeno l'80%.

Nel mondo reale, i test di unità spesso non esistono. D'altra parte, fare qualsiasi refactoring senza test unitari può rovinare totalmente il codice, rendendo la gestione ancora meno probabile che ti permetta di apportare modifiche in futuro. Cosa fare?

Utilizzando uno strumento come ReSharper, è possibile iniziare applicando alcuni dei refactoring "più sicuri". Con cura, non c'è motivo per cui non si possa avere successo usando ripetutamente "Extract Method" per spostare l'ADO.Codice NET in metodi separati, "Crea metodo statico" se non era già statico, quindi "Metodo di spostamento" o "Metodo di preparazione non statico" per spostare il metodo in una classe separata.

Una volta che il codice è stato rimosso, è possibile iniziare a scrivere alcuni test automatici. A questo punto, non hanno bisogno di essere "unit test" nel senso stretto del termine. In particolare, questi test dovrebbero essere autorizzati a lavorare con il database.

Quando si lascia solo con il codice che non può essere facilmente testato con l'unità, è possibile, molto attentamente iniziare a rendere quel codice più verificabile. Puoi fare cose come trasformare serie di metodi statici in metodi di istanza di nuove classi. È inoltre possibile iniziare a introdurre l'iniezione di dipendenza, per rendere più facile il test utilizzando oggetti fittizi. Ma stai attento allo - stai modificando il codice che non ha test automatizzati e utilizzerai dei refactoring che possono effettivamente violare le cose.

Una volta ottenuto il codice adeguatamente testato, quindi è possibile riorganizzare il codice per avere un senso migliore, quindi modificarlo per utilizzare LINQ se lo si desidera.

Answer 2

È ancora possibile sfruttare tutte le stored procedure/funzioni originariamente create per la soluzione con Linq2SQL. Utilizzando qualcosa come le strategie espresse in Working with Legacy Code di Micheal Feather, è possibile creare dei limiti attorno alle regioni dell'applicazione e aggiornarle all'interno di tali limiti.

La strategia che ho usato in passato è mantenere/ignorare il database e i suoi oggetti. Quindi faccio scorrere lentamente le diverse chiamate ADO e sostituisco con le chiamate Linq2SQL finché l'intera applicazione non utilizza Linq2SQL. Trovo quindi più facile trasformare le chiamate ADO precedenti che hanno esposto e passato DataSet/DataTables in entità più appropriate.

altro approccio (per/soluzioni pesanti DataTable DataSet) è di mantenere la chiamate ADO in posizione e invece utilizzare i metodi di estensione AsQueryable() e/o OfType<T>() per trasformare il ds/articoli dt in entità appropriate, quindi aggregare questi cambiamenti in un DAL più coeso