Passaggio agli ORM

Question

Sto giocando con l'idea di introdurre gradualmente un ORM in un'applicazione che supporto.L'app non è molto strutturata e non presenta test unitari.Quindi qualsiasi cambiamento sarà rischioso.Sono ovviamente preoccupato di avere una ragione sufficiente per cambiare.L'idea è che ci saranno meno codici standard per l'accesso ai dati e lì per una maggiore produttività.

Questo suona vero con le tue esperienze?
È possibile o addirittura una buona idea inserirlo gradualmente?
Quali sono gli svantaggi di un ORM?

Answer 1

Consiglio vivamente di procurarsi una copia del libro di Michael Feather Lavorare in modo efficace con il codice legacy (per "Legacy Code" Feathers indica qualsiasi sistema che non sia adeguatamente coperto dai test unitari).È pieno di buone idee che dovrebbero aiutarti con il refactoring e l'introduzione graduale delle migliori pratiche.

Certo, potresti introdurre gradualmente un ORM, utilizzandolo inizialmente per accedere ad alcuni sottoinsiemi del tuo modello di dominio.E sì, ho scoperto che l'uso di un ORM accelera i tempi di sviluppo: questo è uno dei vantaggi principali e di certo non mi mancano i giorni in cui creavo faticosamente a mano i livelli di accesso ai dati.

Aspetti negativi dell'ORM: per esperienza, c'è inevitabilmente una certa curva di apprendimento per affrontare i concetti, la configurazione e le idiosincrasie della soluzione ORM scelta.

Modificare:corretto il nome dell'autore

Answer 2

Il libro "Robert C Martin", che in realtà è stato scritto da Michael Feathers ("Uncle Bob" è, a quanto pare, un marchio di questi tempi!) è un must.

È quasi impossibile, per non parlare dell'enorme dispendio di tempo, inserire test unitari in un'applicazione non sviluppata con loro.Il codice semplicemente non sarà gestibile.

Ma questo non è un problema.Il refactoring riguarda il cambiamento del design senza cambiare la funzione (spero di non aver corrotto troppo il significato lì) in modo da poter lavorare in un modo molto più ampio.

Inizia con pezzi grandi.Imposta un'esecuzione ripetibile e acquisisci ciò che accade come risultato previsto per le esecuzioni successive.Ora hai la tua app, o almeno parte di essa, in fase di test.Non è un test molto buono o completo, certo, ma è un inizio e da lì le cose possono solo migliorare.

Ora puoi iniziare il refactoring.Vuoi iniziare a estrarre il tuo codice di accesso ai dati in modo che possa essere sostituito con funzionalità ORM senza disturbare troppo.Prova spesso:con le app legacy rimarrai sorpreso da ciò che si rompe;la coesione e l’accoppiamento raramente sono ciò che potrebbero essere.

Prenderei in considerazione anche l'idea di dare un'occhiata a Martin Fowler Refactoring, che è, ovviamente, il lavoro definitivo sul processo.

Answer 3

Lavoro su una grande applicazione ASP.net dove recentemente abbiamo iniziato a utilizzare NHibernate.Abbiamo invece spostato un gran numero di oggetti di dominio che avevamo persistente manualmente su SQL Server su NHibernate.Ha semplificato un po’ le cose e ha reso molto più facile cambiare le cose nel tempo.Siamo lieti di aver apportato le modifiche e di utilizzare NHibernate dove appropriato per gran parte del nostro nuovo lavoro.

Answer 4

Ho sentito che TypeMock viene spesso utilizzato per eseguire il refactoring del codice legacy.

Answer 5

Penso seriamente che l'introduzione di ORM in un'applicazione legacy comporti problemi (e potrebbe essere la stessa quantità di problemi di una riscrittura completa).

A parte questo, l'ORM è un ottimo modo per procedere e dovrebbe essere sicuramente preso in considerazione.

Answer 6

La regola per il refactoring è.Esegui test unitari.

Quindi forse prima dovresti inserire alcuni unittest almeno per le cose principali/principali.

L'ORM dovrebbe essere progettato per ridurre il codice boilerplate.Il tempo/problema vs.Il ROI per essere un'impresa spetta a te stimarlo :)

Answer 7

A meno che il tuo codice non sia già strutturato per consentire lo "scambio a caldo" del backend del livello del modello, modificarlo in qualsiasi modo sarà sempre estremamente rischioso.

Cercare di costruire una rete di sicurezza di test unitari su codice scarsamente architettato non garantirà il successo, ti farà solo sentire più sicuro nel cambiarlo.

Quindi, a meno che tu non abbia una forte motivazione aziendale per assumersi i rischi connessi, probabilmente è meglio lasciar perdere.