Modello di dominio: relazioni di identificazione contro oggetti gerarchici

Question

Durante la stesura di un ipotetico modello di dominio, mi sono trovato a chiedermi se l'approccio migliore nei relativi oggetti di dominio sarebbe avere un oggetto di dominio principale contenente un puntatore (l'identificatore del figlio) o se sarebbe un approccio migliore per utilizzare gli oggetti figlio per creare un composito all'interno dell'oggetto padre.

Riesco a vedere i pro ei contro di ogni approccio, principalmente un compromesso tra dimensioni e complessità, essendo ciò a cui si riduce. Tenderei a orientarmi maggiormente verso un approccio di relazione identificativa, poiché non sto anticipando la necessità di eseguire alcun tipo di caricamento lento.

Sebbene non siano direttamente correlati, gli oggetti dominio sono semplici POCO (equivalente .NET di POJO). Sono esplicitamente contrassegnati come serializzabili, poiché esiste una buona probabilità che alla fine si incrociano tra i domini dell'applicazione. A mio avviso, LINQ rende praticabile l'approccio all'identificatore relazionale e non lo prenderei in considerazione se LINQ non fosse disponibile.

Qualsiasi pensiero sarebbe apprezzato!

Modifica: un altro paio di pensieri che potrebbero portarmi ad un approccio solo identificativo. Il primo sarebbe che la politica di memorizzazione nella cache degli oggetti. È del tutto possibile che un oggetto padre e figlio abbiano TTL diversi, come definito dalle loro politiche. Il secondo sarebbe che l'azienda di riferimento potrebbe limitare il riutilizzo degli oggetti, in quanto lo stesso figlio potrebbe essere detenuto da più genitori, nel caso di dati riutilizzabili. Entrambi si riferiscono anche alle dimensioni complessive degli oggetti serializzati.

Answer 1

Uso entrambi i miei POCO. Li genera con un elenco di figli nella classe genitore e un'istanza genitore nella classe figlio.