Come si memorizza un grafico uno-a-molti? Passando radice o passando radice e bambini separatamente?

Question

Come si memorizza un grafico uno-a-molti? Passando radice o passando radice e bambini separatamente?

#1 da (2 voti)
#2 da (1 voti)

2

Supponiamo che nell'applicazione ci sia un tipo Teacher e un tipo Students . Un insegnante può avere un elenco di studenti. Quindi, in progettazione, la classe Teacher ha un campo di tipo Raccolta di studenti (aka Elenco).

Supponiamo di voler registrare (inserire) un nuovo Insegnante con i suoi nuovi studenti.

Potrei creare un oggetto Teacher e impostare il suo campo StudentList . In altre parole, deve essere formato un grafico dell'oggetto, quindi la radice viene passata al livello di accesso ai dati da memorizzare.

o

Potrei creare un oggetto Teacher , quindi creare un elenco di Student s e quindi passare entrambi a Data Access Layer per archiviarlo.

Sono quasi sempre di fronte a questo dilemma. Sono consapevole che dipende dal fatto se il DAL è in grado di rilevare i cambiamenti in un grafico o meno. Ma supponiamo di essere nel perfetto mondo di Persistenza DAL ignoranti.

Quale è meglio?

object-oriented architecture

posta Hans 05.10.2015 - 09:21

fonte

2 risposte

Leggi altre domande sui tag object-oriented architecture

scrivendo un file controller in Python TDD: come testare il modello di dominio

score 2 · Answer 1

Se dovessi scegliere tra i due, sceglierei sicuramente la prima soluzione. Non vedo assolutamente alcun merito nel passare un oggetto Teacher con una lista vuota di Student s insieme ad un elenco indipendente popolato separatamente di Student s, invece di passare un oggetto Teacher con la sua lista di studenti già popolati.

Tuttavia, se dipendesse da me, non sceglierei nessuno di questi due approcci.

Tieni presente che il fatto che l'insegnante abbia una lista di studenti è un'illusione elaborata e mantenuta elaborata che ti fornisce il tuo livello di persistenza. Da un punto di vista relazionalmente normalizzato, l'insegnante in realtà non ha una lista di studenti; invece, ogni studente ha un insegnante o, se uno studente può aver bisogno di avere molti insegnanti, allora questo si realizza attraverso una relazione molti-a-molti.

La relazione many-to-many è implementata come una tabella aggiuntiva contenente righe con coppie di ID insegnante e ID studenti. In questo caso, l'illusione di una raccolta si applica anche agli studenti: uno studente può avere una lista di insegnanti con la stessa facilità con cui un insegnante può avere una lista di studenti. Quindi, quando crei uno studente, perché non crearli con la loro lista di insegnanti già compilati? Chiaramente, questo è assurdo, quindi penso che l'idea di creare entità con relazioni pre-riempite sia assurda.

Quindi, quello che farei è che istanzerei e passerei attorno a entità separate di insegnante e entità studentesche, (senza nessuna relazione pre-compilata tra loro) e poi in passaggi separati specificherò le relazioni tra loro su una base individuale.

score 1 · Answer 2

Né è meglio. Dipende dall'atomicità prevista della modifica e dalla corrispondenza con l'interazione del client.

Se stai manipolando le cose tramite un'interfaccia utente e un utente crea prima un insegnante, quindi crea o collega a uno o più studenti, eseguendoli separatamente e in sequenza è corretto.

Se stai elaborando una richiesta di servizio che raggruppa in classi, devi eseguirle in una singola azione atomica, e questo è espresso in modo più naturale passando l'intero grafico.

Idealmente, il tuo DAL dovrebbe gestire entrambi i casi d'uso, poiché qui gli eventi funzionali sono diversi e hanno diversi vincoli.