Come conciliare OOAD e Database Design?

5

Recentemente ho studiato analisi e progettazione orientata agli oggetti e mi è piaciuto molto. In ogni luogo che ho letto le persone dicono che l'idea è di iniziare con il minimo insieme di requisiti e migliorare nel modo, rivisitando ogni iterazione e migliorandola man mano che sviluppiamo e contattiamo continuamente il cliente interessato al software. In particolare, un corso di Lynda.com ha detto molto: non vogliamo dedicare molto tempo a pianificare tutto in anticipo, vogliamo solo avere il minimo per iniziare e quindi migliorare ogni iterazione.

Ora, ho anche visto un corso dello stesso tipo sulla progettazione di database, e lì dice in modo diverso. Dice che, anche se lavora con l'orientamento agli oggetti, gli piace l'approccio iterativo agile, per il design del database dovremmo davvero dedicare molto tempo alla pianificazione anticipata invece di limitarti ad andare avanti con il minimo.

Ma questo mi confonde un po '. Infatti, il database manterrà dati importanti dal nostro modello di dominio e forse configurazioni del software e così via. Ora, se ho intenzione di rivisitare continuamente l'analisi e il design del modello, sembra che anche la progettazione del database dovrebbe cambiare. Allo stesso modo, se pianifichiamo tutti i database in anticipo, sembra che stiamo pianificando anche tutti i modelli in anticipo, quindi le due idee sembrano incompatibili.

Mi piace un approccio iterativo agile, ma sto anche cercando di ottenere un design migliore per il database, quindi quando si lavora con un approccio iterativo agile, come dovremmo occuparci della progettazione del database?

    
posta user1620696 31.10.2013 - 01:47
fonte

3 risposte

3

Il problema con i database è che contengono dati. Ciò significa che se si desidera modificare la struttura di un database, è necessario far fronte a tutti i dati in esso contenuti, assicurandosi di mantenere la sua integrità dallo schema originale allo schema revisionato.

Non è sempre facile. Introduce rischi. La migrazione dei dati tra le modifiche dello schema può essere difficile da testare. Fondamentalmente, i database possono essere sviluppati in modo iterativo, ma farlo tende a essere un rompicapo.

Il codice, d'altra parte è molto più facile da cambiare. Finché i test sono in atto, è ragionevolmente semplice determinare che il codice refactored fa ancora la stessa cosa dell'originale. Quindi il refactoring e lo sviluppo iterativo funzionano bene sul codice del programma.

Non c'è una risposta definitiva alla riconciliazione di questi elementi. Direi che il consiglio che ti è stato dato è buono, prova a ridurre il numero di volte in cui ristrutturi il tuo database. Questo non significa che non puoi mai cambiare il tuo DB, semplicemente non farlo tutto il tempo. Prova a prevedere le modifiche necessarie su più iterazioni e ad aggiornare lo schema una volta ogni 3 o 10 iterazioni di codifica. Pensa alle modifiche dello schema del database come parte delle versioni principali della tua versione, mentre le modifiche al codice possono essere delle dot release.

    
risposta data 31.10.2013 - 05:54
fonte
2

Il trucco sta nel modo in cui ti avvicini alla fine della persistenza dei dati del tuo codice. Mi piace tenerlo iterato su tutti i fronti.

Se mantieni un buon modello del database (mi piace farlo con MySQL Workbench) e hai una soluzione ragionevole per la persistenza (mi piace usare JPA), puoi cambiare e ridistribuire il database e tutto il codice relativo con relativo facilità.

Purtroppo, l'approccio tradizionale è parziale nell'ottenere tutte le informazioni in modo da ottenere il modello completo di dati pronto, spendendo così molto tempo prima che i prototipi funzionanti possano essere scritti.

Una via di mezzo è la seguente: avere quanti più moduli utilizzati nel processo che sono automatizzati possibile ha la sua persistenza definita e iterare con il resto della struttura di base di dati (viste, stored procedure e tabelle ausiliarie).

    
risposta data 31.10.2013 - 01:56
fonte
1

Capisco che ti abbia confuso. Non è possibile creare un datamodel completo quando si inizierà solo creando una serie minima di funzionalità nella soluzione.

Un buon approccio consiste nell'applicare un buon design alla struttura iniziale. Se il tuo progetto è stato buono, tutte le aggiunte successive non richiederanno una riprogettazione della struttura iniziale (ci sono alcune eccezioni!). Assicurati di leggere su Normalizzazione DB

Quello che noterete in un processo di sviluppo software iterativo è che la struttura dei dati crescerà con la quantità di requisiti che avete creato nel vostro software. Nelle fasi successive di un processo di sviluppo software, la quantità di modifiche richieste diminuisce, quindi anche le modifiche all'origine dati sono meno probabili.

Quando un grande cambiamento è imminente, c'è un po 'di magia che puoi fare per diminuire la riprogettazione necessaria. Ad esempio, è possibile lasciare intatto un datamodel esistente e creare un mapping personalizzato in un livello astratto della soluzione. La maggior parte degli ORM di oggi sono molto adatti a questo.

    
risposta data 31.10.2013 - 09:57
fonte

Leggi altre domande sui tag