architettura dell'applicazione pesante del database

Naviga le tue risposte
2

Un programma che sto attualmente progettando fa un uso massiccio del database, quasi tutto ciò che l'utente fa altera il database o lo legge. Ora ho un'interfaccia che definisce tutte queste operazioni e una classe di database che la implementa.

Il risultato è che quella classe è enorme, contiene la logica per creare utenti, modificarli, creare eventi, mostrare eventi all'utente, modificare, aggiungere amici, aggiungere elementi a un prodotto, ....

Da un lato posso affermare che questo non viola l'SRP, perché l'intero utilizzo è la comunicazione del database. D'altra parte, questo è un sacco di codice per una classe.

Esistono schemi di progettazione che risolvono questo problema o sono accettabili?

    
posta Dylan Meeus 28.11.2014 - 12:55
fonte

2 risposte

5

Sì, penso che tu stia violando l'SRP. Non perché hai tenuto tutto il codice del tuo database in una classe, ma perché hai codice di database per entità completamente diverse (utenti, prodotti, eventi, amici) tutto in un'unica classe. Per lo meno, separa il tuo codice in classi dall'entità a cui è più strettamente legata. Se stai cercando pattern di progettazione, ti consigliamo di leggere il schema degli oggetti di accesso ai dati come punto di partenza.

Se la tua applicazione è davvero talmente "pesante da database", vale la pena considerare che parte della tua logica potrebbe essere spostata fuori dal codice dell'applicazione e in stored procedure / funzioni all'interno del tuo database. Ciò renderebbe il codice della tua applicazione un po 'più gestibile, ma dovresti mantenere il codice in due posti diversi.

    
risposta data 28.11.2014 - 13:40
fonte
5

On the one hand I can argue this does not violate SRP, because the whole use is database communication.

Potresti anche dire che hai una singola classe nella tua applicazione, perché l'intera classe esegue l'elaborazione dei dati.

Non funziona così. Se la tua classe ha:

  • un mix di diversi livelli di astrazione;
  • un mix di cose che possono essere descritte come separate da "e" (la classe gestisce gli elementi e degli eventi e degli utenti )
  • cose che vengono modificate per diversi motivi;

allora dovresti dividere lungo quelle linee.

Potrebbe essere ancora accettabile conservare tutto in una singola classe, ma il ruolo della classe dovrebbe essere "fornire un singolo punto di accesso per tutte le operazioni DB".

In questo caso, la classe dovrebbe essere una classe estremamente sottile, semplicemente inoltrando le chiamate a vari sottocomponenti e non avendo bisogno di modifiche quando (ad esempio) il modello di dati per le modifiche degli utenti.

Dalla mia lista qui sopra, puoi estrarre una o (preferibilmente) più linee guida per il refactoring:

  • diviso per livello di astrazione / tipo di operazione / tipo di query DB
  • diviso per tipo di entità (modello dati utente, modello dati prodotto, ecc.)
  • diviso categorizzando modelli di dati (tabelle e operazioni di gestione degli utenti, prodotti - e loro sottotemi, prezzi, offerte, ecc.)
risposta data 28.11.2014 - 14:37
fonte

Leggi altre domande sui tag

Convalida email in PHP E se qualche lingua trattasse le risorse non esposte come un errore? [chiuso]