Zur Zeit wird gefiltert nach: ef 4
Filter zurücksetzen
Entity Framework 4.3 - Building Blocks oder wie steuer ich die Datenbankversion
Gelegentlich kommt es vor, dass die Datenbankversionen pro Umgebung unterschiedlich sein können. Bei meinen ersten versuchen ist mir das mit den SQL-Server Versionen 2005 und 2008 so ergangen.
Sofort ersichtlich wurde das, wenn die folgende Fehlermeldung im Log zu sehen war:
System.ArgumentException: The version of SQL Server in use does not support datatype 'datetime2'
Um dies in den Griff zu bekommen gibt es das Attribut "ProviderManifestToken" in der EDMX-Datei. Mit dem ERM-Ansatz lassen sich, neben unterschiedlen Datenbanken, auch unterschiedliche Versionen einer Datenbank verwalten und mappen. Ein sehr interessanter Ansatz bei der Realisierung von Standardsoftware.
Nun stellt sich die Frage, wie mache ich das in Code First mit Schema Migrations?
Der Schlüssel liegt dabei in der Klasse DbModelBuilder. Beim erstellen kann damit die Datenbankversion definiert werden.
// default
var model = builder.Build(connection);
// with version
var model = builder.Build(new DbProviderInfo("System.Data.SqlClient", "2005"));
Gerade mit der nächsten Version von SQL Server 2012 wird es sicherlich ähnliche Probleme geben können, wenn die Systemumgebungen trotz ITIL nicht ganz so synchron sind. Bei der erstmaligen Erstellung des Models wird das sicherlich nicht von Bedeutung sein, wohl aber bei Schema Migrations.
Im Blogbeitrag von Arthur Vickers finden sich noch andere interessante Punkte die interessant sind, so auch die Aussage das Pluggable Conventions für den Durchschnittsentwickler frühstens mit EF6 nutzbar werden, wenn überhaupt.
Weitere Informationen zum Thema:
Entity Framework - Ein neuer Workaround für 2nd Level Cache mit dem DbContext
Bisher habe ich den 2nd Level Cache nur über einen Umweg über den ObjectContext zum laufen gebracht. Pawel Kadluczka vom EF-Team hat Ende März einen weiteren Ansatz in seinen Blog veröffentlicht, der ohne den ObjectContext auskommt.
Dieser kann auch in Verbindung mit SchemaMigrations zusammen arbeiten, wenn die Tricks und Kniffe im Beitrag beachtet werden.
Wenn das EF-Team an solchen Workarounds rumbastelt, kann davon ausgegangen werden, dass der 2nd Level Cache weiterhin kein Bestandteil des Kerns von EF werden wird. Zum Beitrag geht es hier lang.
Weitere Informationen zum Thema
Entity Framework 4.1 – Aus der CTP 5 wird EF 4.1
Die Code First-Variante verpasst dem Entity Framework eine neue Version und wird als eigenständiges Update kommen. Ganz bewusst wird hier auf die Kombination mit dem Service Pack 1 verzichtet. Somit wird Code First noch im ersten Quartal bereitgestellt werden.
In meinen Vortrag von der VSone habe ich bereits die Pluggable Conventions verwendet, als Möglichkeit den Konfigurationsaufwand für TPT zu verringern. Diese Pluggable Conventions schaffen es nicht ins EF 4.1. Die Beispiele werden dementsprechend nicht mehr funktionieren.
Was mit dem EF 4.1 auch in DB First und Model First Einzug halten wird, ist die Validierung mit den DataAnnotations. Das finde ich sehr hilfreich, da es mir einen roten Faden im Bezug auf die Validierungsstrategie aufzeigt und unnötige Datenbankanfragen minimieren kann.
Was mit EF 4.1 Code First noch nicht unterstützt wird, sind Stored Procedures. Hier muss man sich im Hinterkopf behalten, was ich in diesem Beitrag aufgezeigt habe. Am besten zeichnet man vor Projektbeginn ein Umweltdiagramm, um alle Stakeholder ermitteln zu können. Gehört zwar zur alten Schule und macht auch fast niemand, aber es hat sich in meinen Augen bewährt.
Weitere Details gibt es im ADO.NET team blog.
Entity Framework 4 - Geplante Verbesserungen am Entity Designer
Der Entity Designer wird einem Facelifting unterzogen. In die ersten geplanten Verbesserungen kann man sich hier einlesen.
Social Bookmarking