Laden...

EF4, POCO Default Values

Erstellt von ZeroQool vor 12 Jahren Letzter Beitrag vor 12 Jahren 3.880 Views
Z
ZeroQool Themenstarter:in
322 Beiträge seit 2006
vor 12 Jahren
EF4, POCO Default Values

verwendetes Datenbanksystem: SQL Server 2008

Hallo zusammen,

gibt es eine Möglichkeit den Propertys einen Default-Value zu geben? Konnte jetzt auf Anhieb nichts in Google finden.

Danke

1.564 Beiträge seit 2007
vor 12 Jahren

Umm... Wie wär's mit dem Constructor?


public class MyPocoEntity
{
    public MyPocoEntity()
    {
        FirstName = "John";
        LastName = "Doe";
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

Z
ZeroQool Themenstarter:in
322 Beiträge seit 2006
vor 12 Jahren

Würde ich dir normalerweise zustimmen, aber das POCO erstellt alls in

public virtual...

Bsp:

 	[DataMember]
        public virtual int PersonId
        {
            get;
            set;
        }
    	[DataMember]
        public virtual Nullable<System.DateTime> BirthDate
        {
            get;
            set;
        }
1.564 Beiträge seit 2007
vor 12 Jahren

Und was hindert dich daran die im Constructor zu setzen? Die virtual Properties braucht EF für Lazy-Loading und Change Tracking.

Allerdings, wenn ich's mir so recht überlege, würde ich die Erzeugung neuer Entitäten eh in eine entsprechende Factory-Methode kapseln, dann gibt's sicher keine Probleme.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

16.807 Beiträge seit 2008
vor 12 Jahren

Die virtual Properties braucht EF für Lazy-Loading und Change Tracking.

virtual wird eigentlich nur für die Relations benötigt - nicht für die "Properties" an sich. So wirds auch vom Visual Studio "EDMX => POCO Entity Generator" erstellt.

Dieser erstellt nebenbei auch einen Constructor, in dem alle Properties ihren Standard-Wert erhalten.

1.564 Beiträge seit 2007
vor 12 Jahren

Hi Abt!

virtual wird eigentlich nur für die Relations benötigt - nicht für die "Properties" an sich. So wirds auch vom Visual Studio "EDMX => POCO Entity Generator" erstellt.

Soviel ich weiß benötigt EF virtual Properties für alle Datenfelder um ein effizientes Change-Tracking in den, zur Laufzeit erzeugten, Proxy-Objekten anzubieten. Sonst muss EF immer alle Werte/Relationen beim Save durchlaufen und mit den Ausgangswerten zu vergleichen. Die virtual Relationen zu anderen Entitäten wird zusätzlich noch für Lazy-/Deferred-Loading verwendet.
Quelle: POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading. Kann aber natürlich sein, dass das evtl. nicht mehr aktuell ist. Allerdings wäre dann Change-Tracking/Lazy-Loading für POCOs fast nur noch über einen Weaver zu realisieren.

Dieser erstellt nebenbei auch einen Constructor, in dem alle Properties ihren Standard-Wert erhalten.

Danke für die Info. Das wusste ich nicht mehr 😃.

Signatur:
speed is a feature

Dickes +1! Ist mir gerade erst aufgefallen. Wird viel zu oft unterschätzt/vergessen.

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

16.807 Beiträge seit 2008
vor 12 Jahren

Kann aber natürlich sein, dass das evtl. nicht mehr aktuell ist.

Inwiefern das aktuell ist kann ich gar nicht sagen.
Aber wenn ich die History im Source Control anschaue, dann habe ich bisher nur mit virtuellen Relationen gearbeitet.

Habe das gerade mal auch getestet.
Erstellt habe ich ein EntityModel mit zwei Entities, die jeweils ein paar Properties und Relations haben. Anschließend durch einen Custom Model Generator (ADO.NET DbContext Generator V4.2 (= EF 4.2 CTP June 2011)) laufen lassen.

Die Default-Values richten sich nach den hinterlegten Informationen im EDMX-Model. Da ich keine Hinterlegt habe wurde nur die Collection initialisiert.

Ergebnis siehe angehängtes Bild.
Rot sind die Typen, weil ich mscorlib nicht im Projekt referenziert habe.

Wird viel zu oft unterschätzt/vergessen. Was einen von vielen andren Entwicklern unterscheidet, kann einen selbst nur fördern 😉

1.564 Beiträge seit 2007
vor 12 Jahren

Aber wenn ich die History im Source Control anschaue, dann habe ich bisher nur mit virtuellen Relationen gearbeitet.

Der Artikel scheint out-of-date zu sein. Habe es jetzt auch gerade mal getestet (T4 Template "ADO.NET Self-Tracking Entity Generator"). Bei dem Template werden Properties nicht virtual, dafür bekommen die Entitäten bei dem Template die Interfaces IObjectWithChangeTracker, INotifyPropertyChanged. Ist mir bislang nicht aufgefallen, weil ich meine Entitäten normalerweise aus einem anderen Tool erzeuge.

Ich glaube ich muss mir das bei Gelegenheit (und schlechterem Wetter) mal genauer anschauen.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

Z
ZeroQool Themenstarter:in
322 Beiträge seit 2006
vor 12 Jahren

Also ich arbeite mit

ADO.NET POCO ENTITY GENERATOR und EF4, deshalb gibt es auch keinen Person() Constructor mit Default-Values. Danke

16.807 Beiträge seit 2008
vor 12 Jahren

Also ich arbeite mit ADO.NET POCO ENTITY GENERATOR

Du benutzt auch ein EDMX ? Dann kannst Du doch über die Property-Settings einer Entity definieren, dass diese eine Default-Value hat, Nullable sein darf etc...
Standardmäßig steht dort "(None)", sodass der Standard-Wert des Typs verwendet wird.

Z
ZeroQool Themenstarter:in
322 Beiträge seit 2006
vor 12 Jahren

Du hast Recht. Danke. Kann ich das ganze irgendwie Global bzw. über das T4 Template abwickeln? Sonst müßte ich jede Entität einzel anpassen.

Danke

Hinweis von Abt vor 12 Jahren

Bitte keine Full-Quotes 😉

16.807 Beiträge seit 2008
vor 12 Jahren

Mh...Ich bin mir nicht sicher was Du meinst. Die Templates werden - eigentlich / zumindest bei mir - automatisch generiert und beachten alles, was definiert werden kann.

Dazu muss das EDMX die Build Action "Entity Deploy" haben und die EDMX über Rechtsklick Add Code Generation Item einem Custom Generator zugewiesen werden. Dieser erstellt dann die nötigen tt-Files und den Rest machen die Templates.
Alles was erweitert werden muss sollte nicht über die Templates, sondern über die erweiterte Klasse erfolgen.

1.564 Beiträge seit 2007
vor 12 Jahren

Hi

ADO.NET DbContext Generator V4.2

ADO.NET Self-Tracking Entity Generator

ADO.NET POCO ENTITY GENERATOR lol! Soviel zum "Standard"...

@ZeroQool:
Wie Abt schon richtig gesagt hat (sorry, für mein Unwissen zu den Features des EDMX Designers), man kann im Designer "Default Values" für Scalar Properties angeben. Bei mir werden die dann auch automatisch in die erzeugen Entity-Classes eingefügt. Wenn das bei dir nicht so ist würde ich evtl. versuchen auf ein anderes T4 Template zu wechseln.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

16.807 Beiträge seit 2008
vor 12 Jahren

lol! Soviel zum "Standard"...

Die Artenvielfalt ist durchaus berechtigt. Es gibt Szenarien, in der Self-Tracking Entities durchaus Vorteile bieten; automatische Aktualisierung aller Daten, zum Beispiel bei Börsensystemen.
Für Web-Anwendungen ist das natürlich aufgrund der Status-losen Verbindung absoluter Quatsch (in meinen Augen). Dafür hat eine andere Technik wiederum seine Vorteile. Am Ende ist und bleibt es eine POCO 😉

Der DbContext Generator ist auch nur ein Übergang aufgrund des CTPs und der Code First Variante. Der DbContext hat eben mittlerweile viele Vorteile gegenüber dem sonstigen ObjectSets.
Man muss eben wissen, welches Szenario für einen sinnvoll ist.