Visibilità dei riferimenti ID alle entità e alle radici aggregate

Question

Visibilità dei riferimenti ID alle entità e alle radici aggregate

#1 da (1 voti)

0

Supponiamo che esista una classe di entità A come questa:

class A {
    public Id { get; private set; }
}

Esiste anche un'altra classe di entità B che contiene un riferimento a A :

class B {
    public Id { get; private set; }
    public aId { get; private set; }
}

Le linee guida sull'impostazione della visibilità dei riferimenti ID ad altre entità e le radici aggregate, come aId nell'esempio sopra, esistono?

Rendere l'entità Id public con private setter sembra una pratica comune, ma implica che anche fare riferimenti ad altri campi Id public è preferibile? Esiste una situazione in cui tale approccio potrebbe causare problemi?

c# domain-driven-design

posta bklaric 02.08.2016 - 14:36

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design

Tabella di progettazione per archiviare la gerarchia Flusso di lavoro di Github per pubblico / fornire base di codice

score 1 · Accepted Answer

Bene nel caso di A.Id , se qualcosa rende quel valore definibile solo dopo che esiste l'oggetto B , non sarai in grado di impostarlo.

Se l'oggetto A deve sempre esistere entro B dall'inizio della durata di B e non cambierà, puoi andare per un setter privato.
Se l'oggetto A può essere impostato dopo o modificato entro la durata di B , mantenere il setter privato e usare un altro metodo per impostare il valore (ed eseguire eventualmente alcuni controlli) o lasciare che il setter sia pubblico.

Per il campo A.Id , esiste fin dall'inizio della vita di A se lo si preleva dal database. Tuttavia se stai memorizzando nel database un nuovo A che non ha ancora il suo Id (sarà impostato dal database), dovrai ricreare il A creato e restituirlo al metodo superiore in modo tale che può usare A.Id . O devi essere in grado di impostare A.Id .

Se vuoi veramente far rispettare qualcosa, sarebbe% nèId essere nullo o, se è impostato, non puoi più cambiarlo. Per A.Id dipende dalle esigenze del dominio.