Zur Zeit wird gefiltert nach: April 1
Filter zurücksetzen

Entity Framework 4.1 - Edmx-Datei vom DbContext erstellen, so funktionierts nach der CTP5

Mit der CTP5 habe ich mich auch mit Fallback-Strategien beschäftigt, da unter anderem die Verwendung von Prozeduren für Create, Update und Delete noch nicht möglich ist. Ein mögliches Szenario habe ich hier beschrieben.

Dieses Szenario habe ich jetzt vorgeholt und wollte es erneut testen, um Tipps für die erste Verwendung geben zu können. Die WriteEdmx-Methode und der Namensraum System.Data.Entity.ModelConfiguration.Edm.Db.Mapping existieren natürlich nicht mehr.

Also habe ich mich mit Reflector auf die Suche begeben und wurde im Namensraum System.Data.Entity.Infrastructure fündig. Das Verhalten wurde komplett überarbeitet und ist aus meiner Sicht viel einfacher zu nutzen als in der CTP5. Nun kann man eine Instanz des Kontexts übergeben und daraus wird das Edmx-File erstellt. In ähnlicher Manier funktionierte es in der CTP4.

Das Beste: Die Ecken und Kanten wurden auch behoben. Während man in der CTP5 nur eine Datei basierend auf den Konventionen erstellen konnte, funktioniert jetzt auch die Erstellung mit benutzerdefinierten Konfigurationen durch die Fluent Mapping API.

Hier ein Codebeispiel:


var ctx = new ManyClassesOneTableBlobContext();

using (var writer = new XmlTextWriter(
        Path.Combine(PATH, "ManyClassesOneTableBlob.edmx"),
        Encoding.UTF8))
{
    EdmxWriter.WriteEdmx(ctx, writer);
}

Ich bin positiv überrascht, dass ist wirklich einfach…

12.04.2011
22:01

T4 Parameter Templates mit dynamischen Parametertypen

In meinen Projekten favorisiere ich mittlerweile den T4-Ansatz unter Verwendung von Parameter-Templates, die mit Hilfe von Metadaten für die Erstellung des Codes verantwortlich sind. Das Haupttemplate (Treiber) hat die Aufgabe die Daten aufzubereiten und ein Metadaten-Objekt an das Parameter-Template zu übergeben. Der Vorteil dieses Ansatzes, ich kann die aufbereiteten Metadaten dazu nutzen, um Konfigurations- und Codedateien zu erstellen, die Logik ist verständlicher, der Austausch ist einfacher und ich erspare mir Redundanzen, da Verarbeitung und Ausgabe getrennt sind. Mit diesem Ansatz eine WCF-Infrastruktur aufzubauen ist sehr praktisch ;-)

Bei kleineren Projekten finde ich es jedoch überdimensioniert, die typisierten Metaklassen in einer eigenen Assembly zu packen, sondern möchte diese im Class-Feature Block des Haupttemplates definieren.

Folgende Abbildung verdeutlicht dies:

Abbildung 1 Haupttemplate mit der definierten Klasse für die Metadaten im Class-Feature Block
Abbildung 1

Die im Class-Feature Block definierte Klasse lässt sich jedoch nicht als Parameter-Typ verwenden. Der Versuch führt zu folgendem Fehler:

Kompilierte Transformation: Der Typ- oder Namespacename "MetadataObject" konnte im globalen Namespace nicht gefunden werden. (Fehlt ein Assemblyverweis?)

Aus diesem Grund ist der Umweg über eine eigene Assembly notwendig. Eine Alternative wäre aber auch der Einsatz des System.Object-Typs als Parameter und das Casting auf den Datentyp dynamic.

Abbildung 2 Aufbau des Parameter Templates, damit die Klasse aus der Hauptvorlage verwendet werden kann.
Abbildung 2

Durch die späte Bindung wird der Aufruf der Eigenschaften ohne Fehlermeldung möglich. Der einzige Nachteil, man muss auf die IntelliSense verzichten, wenn man einen T4-Editor einsetzt. Zudem wird zusätzlich noch eine Referenz auf die Assembly Microsoft.CSharp.dll im Parameter Template benötigt.

Wird mit dieser Vorgehensweise das Haupttemplate ausgeführt, habe ich folgendes Ergebnis:

Abbildung 3 Ausgabe des Quellcodes nach dem Speichern des Haupttemplates
Abbildung 3

Pragmatisch, praktisch, gut … ;-)

Die Klasse ParamTextTempalte befindet sich in der Include-Datei TemplateFileManager.CS.ttinclude. Der Inhalt steht in der Code-Gallery des Tangible T4-Editors unter der Kategorie .ttinclude zur Verfügung.

Abbildung 4 Inhalt der Include-Datei TemplateFileManager.CS.ttinclude verfügbar in der Code Gallery des Tangible T4 Editors
Abbildung 4

Entity Framework 4.1 - Es ist released

Das Entity Framework 4.1 ist fertig. Wie der RC gibt es EF 4.1 als NuGet-Package ohne T4 Templates und Stand-alone Installer. Die Sprachpakete für Deutsch und Co. werden innerhalb des nächsten Monats nachgeliefert.

Weitere Infos findet man hier.

Heute Abend werde ich die Version aktualisieren und schauen, ob ein "spezieller" Unittest, der mit dem ObjectContext funktioniert, nun auch mit dem DbContext erfolgreich durchläuft.

Im Übrigen gibt es auch interessante Unterschiede im Linq-Support, interessant bedeutet in diesem Zusammenhang, ich versteh es einfach nicht, Erwartungskonformität wird wohl definitiv zu einem Wunschgedanken.

 

05.04.2011
12:52

SQL Server - Ausgeführte SQL-Statements auflisten

Mir ist eine Panne passiert, die eigentlich nicht passieren sollte. Ich habe eine SQL-Abfrage erstellt und den Debug-Knopf im Management Studio gedrückt. Danach funktionierte erst mal nichts mehr. Die Abfrage war natürlich auch noch nicht gespeichert, jedoch ein paar Mal ausgeführt worden.

Der erste Gedanke war Query Stats und so konnte ich das SQL-Statement mit folgender Abfrage wieder hervor holen:


SELECT
    cmd.Text	
    , queryStats.last_execution_time
FROM sys.dm_exec_query_stats AS queryStats 
CROSS APPLY sys.dm_exec_sql_text(queryStats.sql_handle) AS cmd 
ORDER BY 2 DESC

Das Management Studio ist glücklicherweise nicht abgeschmiert, hatte nur sehr lange mit dem Debug-Prozess zu kämpfen. Merke: Öfter speichern oder ausführen. ;-)

04.04.2011
21:51

Review Theorie und Praxis und warum es trotzdem schief geht.

Ich habe mal wieder meine alten Aufzeichnungen überfolgen und dabei folgendes Mindmap im Bereich der Prüf-/Testarten gesichtet. ;-) Dieses hat jetzt schon mind. 5 Jahre auf den Buckel.

Interessant an dem Thema ist der Unterschied von Theorie und Praxis. Im Bereich der statischen Prüfverfahren konnte ich so wieder einiges lernen. ;-)

Im letzten Randprojekt lief es folgendermassen ab:

Der Review wurde an eine Firma im Auftrag gegeben, die faktisch von Schulung, Training, Eigene Projekte, Unterstützung von Firmen alles macht. Sollte ich nochmal so eine Situation erleben, werde ich mich vorher genauer erkundigen, ob die Methoden religiös praktiziert werden.

Bleiben wir mal bei der Theorie. Die Herausforderung, das "Team" war interdisziplinär. Laut Lehrbuch würde man das Team aufbauen. Der Teambildungsprozess mit den typischen Phasen Forming, Storming, Norming und Performing wurde schon mal nicht durchlaufen. Zugegeben, man kann nicht immer nach Lehrbuch arbeiten, da häufig auch zu viel Ideologie im Spiel ist, aber die Grundprinzipien sollten in einem Projekt erkennbar sein.

Die Folgen davon:

  • Es gab keine intensiven Beziehungen zwischen den Projektbeteiligten. Versuche wurden mit der Begründung Single Point of Contact an den wichtigen Schnittstellen abgewürgt.
  • Ein Gemeinschaftsgeist für das Projekt bestand auch nicht. Die Folge hiervon, es kam weder ein Team noch eine Arbeitsgruppe zustande, eher ein Gegeneinander.

Dieser Punkt liegt eigentlich in der Verantwortung der Projektleitung und zeigt das Theorie und Praxis zwei Welten darstellen können.

Wie sah nun die Theorie beim Review aus:

TheoriePraxis
Hauptziel eines Reviews ist die frühzeitige Erkennung von Fehlern.Der Review wurde in der letzten Hermes-Phase angeordnet und die Anforderungsspezifikation diente nicht als primäre Grundlage.
Die Prüfung soll den Autor des Quellcodes unterstützen.Die "Wir können alles Firma" stellte eine Liste mit Kritikpunkten bereit, die Anfangs mehrdeutige Aussagen und zum Ende keine Aussagen zur Verbesserung für den Autor bereitstellte. Lediglich 2 Hinweise waren wirklich brauchbar, da diese auf der Integrationsumgebung messbar waren.
Ergebnis ist eine Mängelliste mit dem entsprechenden Status.Von 4 möglichen Vorgehensmodellen und Methoden, nutzte die "Wir können alles Firma" die Gelegenheit ihr Vorgehensmodell als den Quasi-Standard zu erklären und Werbung für ihre Methode zu machen. Natürlich wurde die Gelegenheit nicht ausgelassen, ein Grüppchen für sich zu gewinnen. Bei diesem Projekt war das auch nicht schwierig. Das eigentliche Ziel wird dabei ersichtlich und muss von mir nicht ausgeschrieben werden.

Abschliessend kann man sagen, das in jeden Witz auch ein wenig Wahrheit liegt:

Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles funktioniert und keiner weiss warum. In diesem Projekt waren Theorie und Praxis vereint, nichts funktionierte und keiner wusste warum. ;-)

Das Projekt hat aber auch ein Vorteil: Nachdem ich dieses "Chaos" erlebte, schätze ich die langjährigen Geschäftspartner noch mehr. ;-)

Translate this page

Kategorien