Migrazione di .NET ORM personalizzato a Entity Frame / Dapper

asp.net-web-api c# dapper migration mysql

Domanda

Ho ereditato un progetto di dimensioni enormi e un po 'labirinto. Il traffico è abbastanza consistente da voler ottimizzare l'accesso ai dati, quindi ho iniziato a convertire alcuni servizi WCF invocati da javascript a Web API.

Sfortunatamente, le chiavi primarie del database (non l'incremento automatico) sono anche gestite da un ORM personalizzato interrogando una funzione MySQL che restituisce il successivo set di ID da utilizzare. L'ORM quindi li memorizza nella cache e li serve fino all'applicazione. Il database stesso è una sempre crescente 2 TB di dati, che renderebbe significativo il tempo di inattività.

Avevo programmato di utilizzare Dapper perché in passato mi sono piaciuti facilità / prestazioni, ma estendere questo database da questo ORM personalizzato sembra scoraggiante e soggetto a errori.

Domande:

  • Qualcuno ha qualche consiglio per affrontare un progetto su larga scala?
  • Dovrei concentrarmi maggiormente sulla migrazione del database in una struttura dati completamente nuova? (ha bisogno anche di una normalizzazione significativa!)

Risposta accettata

La mia modesta opinione :

Una regola empirica quando si affronta il codice legacy è: se qualcosa funziona, mantienila così. Se necessario, apportare una modifica o un miglioramento . Le ragioni principali sono:

  • L'effetto della riprogettazione è quasi zero quando si desidera aggiungere un valore aziendale al sistema.
  • Il sistema, buono o cattivo, funziona. Non importa la cura che hai, puoi sempre pasticciare qualcosa con un cambiamento strutturale.

Inoltre, dipende molto dal piano dell'azienda i motivi per cambiare (aggiungere una funzionalità, correggere un bug, migliorare la progettazione o ottimizzare l'utilizzo delle risorse). La mia umile esperienza mi dice che il tempo e il budget sono molto importanti, e anche se vogliamo sempre ridisegnare (o in alcuni casi, codificare da zero), la cosa più importante sono gli obiettivi di business e il valore aggiunto.

Nel tuo caso, forse non è necessario cambiare tutto l'ORM. Se si dice che gli ID sono memorizzati nella cache, un approccio migliore sarebbe modificare i PK, aggiungendo su di essi la proprietà identity (con il valore di partenza appropriato su ogni tabella). Dopodiché puoi eliminare quella particolare parte del codice che ottiene gli ID successivi.

In alcuni casi, un database non normalizzato ha le sue ragioni. Ho visto casi in cui i dati vengono copiati nelle tabelle per evitare il join, che influisce sulle prestazioni. Sto parlando di milioni di dischi ...

Motivi per cambiare l'ORM: forse se è inefficiente, o se non chiude il codice non gestito (in questo caso un approccio migliore è implementare l'interfaccia IDisposable). Se funziona, forse un approccio migliore è quello di utilizzare un nuovo ORM una volta che è necessario creare nuove funzionalità. Se il progetto ha bisogno di un refactoring per scopi di ottimizzazione, la modifica deve essere applicata nei colli di bottiglia, non nell'intero codice.

C'è molta discussione sull'argomento. Una buona risorsa raccomandata è "Lavorare efficacemente con il codice legacy" di Michael Feathers o "Iniziare con DDD quando sono circondati da sistemi legacy" di Eric Evans.

Saluti!



Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché