Riutilizzare i metodi CRUD di dati nel livello di accesso ai dati, ma vengono aggiornati troppo rapidamente

Il problema principale sembra essere che le interfacce legacy non sono comprese e non sono attendibili. Non è possibile risolvere questo problema ignorandolo - e aggiungere altri membri ad-hoc sta peggiorando attivamente.

La linea di fondo è che le interfacce con le classi devono essere chiare, piccole, affidabili, ben documentate e idealmente solo su una singola responsabilità (fare riferimento a Principio di responsabilità singola ).

Tecniche come refactoring possono essere utilizzate per raggiungere questo obiettivo ideale. Ricorda: ci vorrà uno sforzo consapevole per migliorare la situazione.

Supponendo che la tua organizzazione abbia il diritto di accedere e modificare il codice, la cosa giusta da fare è:

1. Pianifica le attività mancanti nel tuo progetto come: controllo del codice sorgente, localizzazione del codice mancante, sistema di apprendimento corrente, ecc.

2. Trova il codice sorgente per il sistema che stai modificando. A meno che l'applicazione non sia banale, molto probabilmente sarà utile specialmente se è ancora in produzione.

3. Studia bene lo schema e il codice sorgente e pianifica di riutilizzarlo. Puoi trovare informazioni che non conosci come dipendenze archiviate che non sono ovvie o regole aziendali speciali.

4. Non scrivere un nuovo codice simile al vecchio codice a meno che non ci sia un grosso problema con il vecchio codice. Devi avere una politica chiara del perché ci sono 2 classi differenti per Cliente per esempio, altrimenti la manutenzione e il test saranno dannosi.

Non capisco il tuo punto (n. 3).

L'unica scusa valida per non riutilizzare il codice del sistema esistente, INMO, è se si sta migrando il sistema per utilizzare un nuovo framework o non è possibile accedere al codice per motivi tecnici o legali. Un sistema deve avere un ordine interno e una struttura adeguata, non può essere un sistema di qualità se assomiglia alla stanza di uno studente universitario!

In un DAO puoi restituire 3 colonne dalla tabella A, unite con 2 colonne dalla tabella B, ecc. Forse 4 tabelle vengono toccate in una singola transazione. Sarà una necessità creare un nuovo metodo per nuove funzionalità, anche su tabelle esistenti. Le possibili permutazioni sono infinite. Non è possibile coprire ogni interazione del database con i metodi CRUD generici.

In realtà è possibile coprire ogni interazione con CRUD generico, ma sarebbe come forzare un cerchio attraverso un buco a forma quadrata.

Di solito una sorta di framework fornisce accesso CRUD generico alle tabelle. I metodi sono spesso progettati per lavorare su 1 record alla volta. Se rientri in questo ambito, utilizza i metodi CRUD generici. Ma non si vorrebbe usare questi metodi per aggiornare 5 milioni di file dato che farebbero letteralmente 5 milioni di aggiornamenti separati. (Inoltre, tendono a aggiornare in modo ridondante tutte le colonne della riga, modificate o non causando problemi di blocco). Non puoi utilizzarli per le funzionalità transazionali se non sono transazionali.

Identifica solo quando utilizzare i metodi CRUD generici rispetto ai metodi personalizzati.