Posso rappresentare una relazione molti a molti come una relazione composita nel modello a oggetti?

Penso che tu stia confondendo l'entità del modello di dominio e l'amp; cardinalità delle relazioni con la navigazione mediante un'implementazione tecnologica.

Il modello di dominio è un'astrazione che coinvolge entità e relazioni potenziali (cardinalità), che implica la navigazione bidirezionale in astratto, indipendente da qualsiasi implementazione (tecnologia), mentre la navigazione all'interno di un'implementazione (tecnologia) è una mappatura del modello di dominio astratto a un modello relazionale specifico e / oa uno specifico modello di oggetto.

Nel modello relazionale, la navigazione funziona in modo bidirezionale tramite chiavi esterne e amp; join. Potrebbe funzionare male, e se è così, possiamo introdurre un indice per aiutare. Un indice cambia solo le prestazioni e né la capacità né la sintassi di come navigare in entrambe le direzioni.

Per la tecnologia del modello a oggetti, la navigazione richiede generalmente riferimenti, ad es. come collezione, per n: 1 o n: m, o come campo per 1: n.

L'assenza di un riferimento o di una raccolta in un'entità del modello oggetto preclude la navigazione efficace a quel livello (dell'oggetto); tuttavia, questa assenza non impedisce in realtà una relazione di modello di dominio tra entità in astratto. Per reiterare, le capacità di navigazione e / oi costruttori mancanti non impediscono effettivamente al modello di dominio di avere relazioni, ma ostacola davvero il codice che tenta di creare & navigare le relazioni a livello di oggetto.

Can I represent a many to many relationship as a composite relationship in the object model?

È possibile rappresentare una relazione n: m come un'associazione tra due entità: ciascuna entità potrebbe in genere avere una raccolta navigabile che si riferisce all'altra.

Se ometti l'una o l'altra collezione dell'entità, ciò ostacolerà significativamente la navigabilità (e certe costruzioni) ma il modello di dominio astratto che ha una relazione n: m tra entità può ancora contenere.

Se impazzisci ed elimini entrambe le raccolte navigabili, puoi comunque rappresentare la relazione n: m usando un mirror più diretto della tabella di associazione, magari usando le tabelle hash.

Se, ad esempio a livello di oggetto, manteniamo collezioni navigabili in entrambe le entità (per una relazione n: m), questo rappresenta effettivamente dati duplicati.

Nel modello relazionale, questi dati sarebbero refactored in una tabella di relazioni e godono di normalizzazione, cioè rimuovendo alcune duplicazioni (anche beneficiato dell'aiuto della navigazione bidirezionale).

In qualsiasi rappresentazione, dovremmo considerare lo stato essenziale rispetto allo stato derivato. Lo stato derivato è duplice e ha un overhead di manutenzione (poiché senza attenzione può andare fuori sincrono con l'originale / essenziale, anche se spesso considerato valido per quel costo).

Naturalmente, quando c'è uno stato simmetrico, è arbitrario considerare essenziale e derivato.

In termini di tecnologia relazionale, il mantenimento dello stato derivato per le prestazioni è chiamato de-normalizzazione; in questi e ancora altri cerchi, potrebbe essere chiamato il caching.

Il problema di dare una risposta chiara qui è che composizione e associazione hanno una definizione più chiara di quella che hai dato allo sport.

Se prendiamo lo sport per significare qualcosa che vive indipendentemente da una singola persona, allora la composizione non è giusta.

Se prendiamo lo sport per significare che qualcosa esiste solo per quella persona che la sua multa.

Se trovi che insoddisfacente non sei solo.

In realtà abbiamo bisogno di pensare a cosa stiamo modellando qui perché solo sapere cosa sta succedendo nel database non è sufficiente per sapere come modellarlo con gli oggetti. È allettante pensare che ci sia sempre una traduzione 1 a 1 da fare tra DB e il modello a oggetti, ma non c'è. In realtà, questo problema ha un nome: l'errore di impedenza relazionale dell'oggetto .

È a causa di tale discrepanza che posso vedere diversi modi per costruire un modello a oggetti di ciò che sta accadendo nel tuo database. Quello che selezionerei dipende interamente dalle tue regole di business e molto meno che da ciò che sta accadendo nel tuo database o anche se hai un database.

Se tutto quello che vuoi fare è registrare la mappatura tra questi puoi farlo con questo:

PersonPlaysSport(Person person, Sport sport);

Fatto in questo modo, gli oggetti Person e Sport non sanno nemmeno che l'altro esiste, il che può essere una buona cosa.

Ma prima di farlo considera se ti aiuta davvero. Servirebbe meglio le regole aziendali se Person ha preso un List<Sport> ?

È davvero impossibile per me dire dalla tua domanda perché non parli dei tuoi reali bisogni. Vuoi solo una semplice regola cookie cutter che dice che quando il DB sembra così gli oggetti dovrebbero apparire così. Non è così semplice. Ci sono un sacco di librerie di binding dei dati che le persone ti vendono che fingono che sia, ma che ignorano il problema.

Can I represent a many to many relationship as a composite relationship in the object model?

In senso stretto, sì puoi. Ma quando lo fai, stai dicendo molto di più che le tabelle del database che ci hai mostrato stavano dicendo. Potresti anche dire qualcosa che non dovresti. Essere composti da qualcosa significa essere infranti senza di essa. Significa che hai bisogno che funzioni affinché tu possa lavorare perché fa parte di ciò che sei. Questo è più di quanto stessero dicendo le tabelle DB. È più di quello che possono dire.

Per me sembra che tu cerchi di adattare una soluzione in un modello che non comprendi completamente e che è complesso per sua natura.

Quello che dovresti fare è fare un passo indietro di un secondo e pensare a PERCHE 'vuoi questo e non come lo fai tu.

Non inserire qualcosa in un paradigma perché ritieni che sia una buona scelta, prima di sapere realmente qual'è il tuo obiettivo.

Un'altra cosa, prova a modellare, in pseudo-codice, il modo in cui vorresti che fosse il grafo del modello.