modello di oggetto e modello di dati

3

Ho sentito / letto cose miste su come iniziare con un modello di oggetti o un modello di dati. E più persone dicono di iniziare con un modello di oggetti in quanto faciliterà la modellazione dei dati.

La mia domanda è: non dovrebbe un modello di oggetto guidare sempre la progettazione del modello di dati? Perché e quando un design del modello di dati sarebbe diverso da un modello di oggetto?

Se abbiamo un buon modello di oggetti, non dovremmo tradurre le classi nelle tabelle? E le associazioni di classi come relazioni tra tabelle?

    
posta user793468 22.04.2014 - 17:57
fonte

5 risposte

3

La domanda è: la tua app serve il database o il database serve l'app?

Se puoi descrivere la tua app / sito web come "skin" su un database, puoi iniziare con la struttura / lo schema del database e codificare il CRUD perché il comportamento dell'app è quello di gestire i dati sul disco. Potresti colpire alcuni dossi in mezzo alla strada.

Se questo non è il caso, devi affrontare il comportamento dell'app oltre al CRUD. Ci saranno informazioni conservate nell'app che non arriveranno mai al database. Gran parte della logica può essere codificata senza il database. Ciò può aiutare con il test dell'unità o forse come guida per mantenere il codice organizzato e separare le esigenze di archiviazione dei dati.

Chi lo sa. La tua app potrebbe non avere bisogno di un database o qualcosa di semplice come un file di testo.

    
risposta data 22.04.2014 - 18:52
fonte
2

La domanda non è molto ricca di fatti concreti. E fatti pratici sicuramente guideranno su quale modello potrebbe essere migliore per cominciare. Detto questo:

  • se si inizia con un modello relazionale e si ottiene il modello a oggetti, il modello a oggetti sarà concettualmente più divergente (e quindi quasi certamente meno utile) da ciò che si intende rappresentare rispetto a quando si inizia con il modello a oggetti

  • se inizi con i modelli oggetto, sarai sempre in grado di modellarti in modo relazionale. tuttavia, se il tuo modello a oggetti è complesso, potresti aver bisogno di alcune abilità di modellazione relazionale da moderata a esperta per fare la "traduzione", qualcosa di molti (la maggior parte?) sviluppatori orientati agli oggetti sono carenti in

risposta data 22.04.2014 - 18:17
fonte
0

Per alcuni motivi i due modelli potrebbero essere diversi:

  • devi usare un database esistente
  • un modello di dati direttamente modellato come il modello di oggetti potrebbe non fornire le prestazioni richieste
  • non tutte le classi finiscono nello spazio di archiviazione
  • come commentato da @CodeART, potrebbe essere necessario utilizzare una diversa tecnologia di archiviazione e un database relazionale
risposta data 22.04.2014 - 23:57
fonte
0

Ho trovato il modo migliore per iniziare sempre abbozzando un modello di dominio logico. Questo tipo di modello è indipendente dall'implementazione e si concentra sull'identificazione dei concetti chiave e delle loro relazioni. "Domain Driven Design" di Eric Evan è un ottimo riferimento per questo.

Il prossimo passo è progettare il modello di implementazione. Per questo, una buona regola è quella di determinare l'interfaccia che i client useranno per interagire con il tuo modello e iniziare da lì.

Ad esempio, se si sta costruendo un nuovo sistema OLTP utilizzando un framework basato su ORM (come Rails o Grails), i servizi e i controller interagiranno con il modello utilizzando l'interfaccia ORM. Per questo motivo, vorrai iniziare con la progettazione del modello di oggetto e lasciare che il modello di dati segua da quello. I framework ORM hanno ciascuno i propri modi preferiti per modellare i concetti orientati agli oggetti a livello di database e seguendo il modo preferito dal framework saranno più veloci e meno bug. Se si progetta il modello di dati per primo e poi si esegue il mapping al framework ORM, si può finire per dover passare da un anello all'altro per farlo funzionare correttamente.

D'altro canto, se stai costruendo un sistema OLAP supportato da un data warehouse in stile Kimball, probabilmente ci sarà una varietà di client che accedono ad esso, come app personalizzate e strumenti di BI. Un'interfaccia comune da utilizzare in questo caso è l'accesso diretto a SQL. Offre una grande flessibilità e consente ai clienti di sfruttare tutta la potenza del database. Quindi, in questo caso, prima dovresti concentrarti sulla progettazione del database.

    
risposta data 23.04.2014 - 04:35
fonte
-1

O potresti voler iniziare con un modello comportamentale. Dipende dal problema in questione. Uno degli obiettivi chiave della modellazione è assistere le discussioni con le parti interessate non tecniche. Da questo punto in vista è utile inquadrare il modello nel contesto che è più intuitivo per gli stakeholder. Se queste parti interessate sono profondamente immerse nei flussi di processo, potrebbe essere meglio iniziare da lì, capire quali dati sono necessari per supportare il comportamento e pensare a come raggruppare comportamenti e dati negli oggetti un po 'più tardi. Evidentemente eresia nel mondo "Gli oggetti sono la risposta ad ogni problema" ... ma potrebbe darti un migliore livello di comunicazione con i tuoi stakeholder e quindi un prodotto con un livello più alto di soddisfazione degli utenti.

David Hetherington

    
risposta data 23.04.2014 - 16:47
fonte