Laden...

EF Code First - Wo erzeugt man ein Instanz eines Navigationproperties?

Erstellt von SharpDeny vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.030 Views
S
SharpDeny Themenstarter:in
5 Beiträge seit 2016
vor 4 Jahren
EF Code First - Wo erzeugt man ein Instanz eines Navigationproperties?

Hallo liebe Community,

ich wollte einmal fragen, wie man es richtig macht... und zwar nehmen wir folgendes Beispiel:

public class Details
{
	public virtual Int32 ID { get; set; }

	public virtual String A { get; set; }
	public virtual String B { get; set; }
	public virtual String C { get; set; }
}

public class User
{
	public User()
	{
		MyDetails = new Details();
	}

	public virtual Int32 ID { get; set; }

	public virtual Details MyDetails { get; set; }
}

oder

public class User
{
	public virtual Int32 ID { get; set; }

	Details _MyDetails;
	public virtual Details MyDetails 
	{ 
		get{ return _MyDetails ?? (_MyDetails = new Details()); }
		set{ _MyDetails = value; }
	}
}

Oder gar komplett anders?

Grüße
SharpDeny

16.806 Beiträge seit 2008
vor 4 Jahren

Hi,

es gibt kein ASP.NET Code First - Du wirst wohl Entity Framework Code First meinen; also Datenbankschema via Code.
Habe daher auch den Titel angepasst.

Prinzipiell sieht das nicht korrekt aus. Nur Navigation Properties sind virtual.
Die Klasse sollte auch eher UserEntity statt User heissen, da es ja nur eine Datendarstellung ist und kein Business Modell.

Mach einfach mal nen Tutorial durch; da lernst am meisten.
https://www.entityframeworktutorial.net

Ob man User Details wirklich in eine extra Entität packt: kommt drauf an.
Es gibt auch keine pauschale Vorschrift, wo man Instanzen erzeugt; das kommt auf die Logik an.

S
SharpDeny Themenstarter:in
5 Beiträge seit 2016
vor 4 Jahren

Du wirst wohl Entity Framework Code First meinen; also Datenbankschema via Code.

Dankeschön, genau das meinte ich - Allerdings habe ich

Prinzipiell sieht das nicht korrekt aus. Nur Navigation Properties sind virtual.
Die Klasse sollte auch eher UserEntity statt User heissen, da es ja nur eine Datendarstellung ist und kein Business Modell.

Die Namensgebung habe ich bei diesem Beispiel jetzt nicht beachtet - sorry.
Das virtual benutze ich, da ich diese Libary benutze.
Aufgrund des Original-Properties.

Mach einfach mal nen Tutorial durch; da lernst am meisten.

>

Das habe ich mir die Tage bereits angeschaut gehabt 😃 - Allerdings habe ich hierzu nichts finden können.

Ob man User Details wirklich in eine extra Entität packt: kommt drauf an

Ob es an diesem Beispiel Sinn macht oder nicht sei mal dahingestellt. Mir geht es primär darum, dass das Objekt immer der Datenbank angelegt wird bzw. nicht doppelt erzeugt wird und wieder geladen werden kann, sofern es vorhanden ist.

Vielen Dank für deine Hilfestellung

Grüße
SharpDeny

16.806 Beiträge seit 2008
vor 4 Jahren

Mir geht es primär darum, dass das Objekt immer der Datenbank angelegt wird bzw. nicht doppelt erzeugt wird und wieder geladen werden kann, sofern es vorhanden ist.

Eigentlich würde man es vermeiden, dass man 1:1 Entitäten so erzeugt, dass sie pflichtmäig da sind.
Da würde man es lieber in eine Entität packen und beim Lesen mit Projektionen arbeiten.

So wirst Du beim Lesen immer ein Join brauchen, was prinzipiell in Sachen Performance nicht gut ist.
Aber wie gesagt: da gibt es keine pauschale Antwort für.

 Details _MyDetails;
    public virtual Details MyDetails
    {
        get{ return _MyDetails ?? (_MyDetails = new Details()); }
        set{ _MyDetails = value; }
    }

Würde man aber so oder so nicht machen.
Wenn Du sagst, dass Details immer ezeugt werden, kann es hier prinzipiell nicht zu einem Null kommen - wenn doch ist in Summe Deiner Beschreibung ein Programmierfehler.