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
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ß.
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;
}
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ß.
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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ß.
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 😉
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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ß.
Also ich arbeite mit
ADO.NET POCO ENTITY GENERATOR und EF4, deshalb gibt es auch keinen Person() Constructor mit Default-Values. Danke
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
Bitte keine Full-Quotes 😉
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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ß.
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code