Avere chiavi esterne in oggetti aziendali

Eviterei il più possibile le relazioni bidirezionali, poiché possono portare a problemi di sincronizzazione ( Child può finire per avere un ParentId obsoleto).

Detto questo, un riferimento unidirezionale a un altro oggetto dal suo solo ID può essere molto utile.

È un modo molto naturale di tagliare un grafo di oggetti a fette che può essere caricato in memoria dal database su richiesta, invece di idratare l'intero grafico in una sola volta. Molto più naturale di un complicato meccanismo di caricamento pigro IMO. I riferimenti per ID sono spesso usati in Domain Driven Design dove queste sezioni sono aggregati autonomi.

Le chiavi vengono utilizzate per informare le relazioni e rafforzare l'integrità referenziale. Se hai bisogno della chiave ParentId per vivere nell'oggetto Bambino dipende dal fatto che ti trovi in una situazione in cui stai lavorando con un oggetto Bambino e devi conoscere il suo genitore. In generale, suggerirei che è buona norma includere la chiave nell'oggetto Child perché consente di trovare l'identità del Parent senza passare attraverso l'oggetto Parent.

Potresti persino imbatterti in una situazione in cui stai lavorando con un insieme di oggetti figlio indipendente dagli oggetti padre. In tal caso, è possibile decorare l'oggetto Bambino con un insieme minimo di proprietà dall'oggetto padre (nome, ad esempio) se sono necessarie tali informazioni anziché generare l'oggetto principale completo. La tua soluzione dipenderà dalle specifiche del tuo caso d'uso, dalla lingua che stai utilizzando, dal fatto che ti aspetti che questi oggetti siano di lunga durata, dal costo della raccolta dei dati obsoleti, ecc.