Mudu’s Blog

Datenbankdiagramm von SQL Server 2008 in Visio 2007

Heute habe ich meine erste Frage auf stackoverflow.com gestellt. Die Plattform ist in der Betaphase, und darauf gestossen bin ich vor längerer Zeit über codinghorror.com, dem bekannten Blog von Jeff Atwood. Eine sehr coole Plattform, jedem Entwickler zu empfehlen!

Meine Frage ging um Microsoft Visio 2007 und den Microsoft SQL Server 2008. Ich wollte ein Datenbankdiagramm machen (natürlich per Reverse Engineering und nicht etwa von Handschuh), leider geht das nicht. Keine Stunde später hatte ich meine Antwort, zitiert aus den Microsoft-Foren:

Further investigation reveals that this is expected behavior for Visio 2007. When Visio opens a connection using the Visio SQL Server Driver it checks the server version and since SQL Server 2008 shipped after Visio 2007 it doesn’t recognise SQL Server 2008 as a supported version and closes the connection. You can wait for a future version of Visio to ship which does recognise SQL Server 2008 or use the Visio Generic ODBC driver which can successfully open connections to SQL Server 2008. A third option is to use a copy of SQL Server 2005 for initial reverse engineering. The Visio team is aware of this issue.

Das ist natürlich noch uncool.

PostgreSQL mit .NET via ODBC

Wichtig: Im Zusammenhang mit der LAP 2007 steht der Inhalt selbstverständlich wie alle anderen Dokumente unter der Bierlizenz (siehe LAP-Wiki). :)

Die Herren, für morgen ein kleines Sample, wie aus .NET auf eine PostgreSQL-Datenbank zugegriffen wird:

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Odbc;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using(OdbcConnection cn = new OdbcConnection(”Dsn=DateNDrive”))
            {
                cn.Open();
                // Important: It seems necessary that table names must be in
                // double quotes!
                using(OdbcCommand cmd
                    = new OdbcCommand(”select * from \”public\”.\”Fahrzeug\”", cn))
                {
                    using(DataSet ds = new DataSet())
                    {
                        using(OdbcDataAdapter da = new OdbcDataAdapter(cmd))
                        {
                            da.Fill(ds);
                            foreach(DataRow dr in ds.Tables[0].Rows)
                            {
                                Console.WriteLine(String.Format(”{0} {1}”,
                                    dr[”Marke”], dr[”Typ”]));
                            }
                        }
                    }
                }
            }
        }
    }
}

Die Datei ist auch zum Herunterladen verfügbar. Erweiterungen kann jeder selbst vornehmen. :)

Die ODBC-Verbindung muss natürlich vorhanden sein. Man erstellt sie unter Windows mithilfe des “Data Sources (ODBC)” Administrative Tool (”%SystemRoot%\system32\odbcad32.exe”). Folgen Sie den Anweisungen, drücken Sie “Weiter”, akzeptieren Sie die Allgemeinen Geschäftsbedingungen für die Einrichtung einer Datenbankverbindung.

TechTalk/Hands-on Lab "Silverlight 2 Beta"

Letzte Woche hatte ich das Vergnügen, am MSDN TechTalk und Hands-on Lab zu Silverlight 2 dabei zu sein. Mit dem Lab wollte es leider aus technischen Gründen nicht klappen, die Speeches waren jedoch äusserst interessant. Die Präsentationen von Ronny Saurenmann und Sascha Corti stehen auf der Microsoft-Webseite bereit. Die “Hands-on Lab”-Unterlagen hat Sascha Corti in seinem Blog-Post “Silverlight 2 Beta 1 - End-to-End Hands-On Lab” veröffentlicht.

Die Speeches gaben einen Überblick über Silverlight und hoben einige Features hervor. Hier sind einige Elemente lose zusammengetragen. Interessant waren für mich besonders die Möglichkeiten bei der Arbeit mit Daten. An der Modifikation des Aussehens von Steuerelementen habe ich (persönlich) eher weniger Interesse.

• Cool fand ich das Silverlight Data Grid. Zumindest die Demonstration der Möglichkeiten war beeindruckend und ich habe ähnliche Möglichkeiten wie in der Windows-Entwicklung (kein Paging- und Postback-Käse wie im “normalen” Web). Besonders das “Inline-Editing” ist praktisch.
• Fehlen tut in der aktuellen Version (Beta 1) noch die Drop Down Box. Im Manual zum Lab ist eine Anleitung enthalten, selbst eine zu bauen, jedoch lässt sich meiner Meinung nach nicht in Minuten aus einer Text- und einer List-Box eine vollwertige Drop Down Box bauen. Das Steuerelement verhält sich, obwohl subtil, total anders als das Original. Man gehe jedoch davon aus, dass in der finalen Version eine Drop Down Box dabei sein.
• Silverlight bietet keine DataSet-Unterstützung. Der empfohlene Weg sei, eine List<T> (bzw. “Custom Objects”) zu verwenden, mit dem LINQ-Helper alle geänderten Werte zu suchen und zurück an die Datenquelle (in der Regel wohl an einen Web Service) zu senden.
• Silverlight unterstützt nur asynchrone Datenabfragen (Web Service, etc.). Dies ist logisch, schliesslich würde andernfalls der Browser des Benutzers stillstehen.
• Data Binding ist weitgehend unterstützt, die Anwendung gleich wie bei der Windows Presentation Foundation (WPF). Wichtig in diesem Zusammenhang: “DataContext”- und “ItemsSource”-Properties.

Bei diesen Präsentationen sah ich auch des öfteren LINQ in Anwendung. Dies war sehr interessant, da ich noch nie damit gearbeitet habe, gehört jedoch in einen anderen Topf.

Für einen .NET-Programmierer ist Silverlight bestimmt eine schöne Sache, um “interaktive Web-Applikationen” zu entwickeln. Das Plug-In ist für den Internet Explorer, Mozilla Firefox und Safari verfügbar und unter Linux als “Moonlight” bekannt. Ich wage nicht, über die potentielle Verbreitung ein Urteil zu fällen respektive zu urteilen, ob die Unterstützung dieser Plattformen in den meisten Fällen ausreicht.

Da bleibt noch eine Frage: Warum, wieso muss das GUI von Blend so schaurig unpassend schwarz sein? Bsst, ganze Strasse dunkel, warum?

Zum Schluss noch einige Zitate zur Auflockerung:

• “In Silverlight 1 you didn’t even have a text box!”
• “In this case I’d already said it’s the system but I’m sure it’s me who did something wrong.” (der Internet Explorer verabschiedete sich abrupt)
• “There is coffee, we know how important this is for you.”
• “Well, a demo application without an animation is no demo application.”

Data Source Independent DAL

Another short piece of personal learning. Ich markiere für einmal den grossen Architekten. :)

Die Idee eines Data Access Layers ist gemeinhin, Datenzugriffe datenbank- oder sogar datenquellenneutral (neben relationalen Datenbanken allein können ja auch Textdateien oder ein Web Service als Datenquelle dienen) zu halten. In der Praxis ist dies nach meinen Erfahrungen nicht immer genau so der Fall, wie dies die Theorie anpreist.

Die Theorie sagt: Der Presentation Layer präsentiert Daten und enthält keine Logik (höchstens formelle Prüfung oder Plausibilisierung von Eingaben), der Business Layer hantiert mit den Business-Objekten und implementiert die Logik, der Data-Access Layer liest und speichert die Daten und abstrahiert die Zugriffe auf die Datenquelle auf allgemeinem Level.

Ich wollte nun einen Business Layer, der weder von der Datenquelle abhängt noch hunderte Zeilen Code enthält, um die netten Rückgabewerte und Ausgabeparameter wieder in Objekte umzubauen. Ich wollte im DAL auch keine Strukturen definieren, dessen Felder denjenigen im Business-Objekt entsprechen. Ein Objekt (Business Entity!) soll “as it is” ohne weitere Bearbeitung zur Speicherung gereicht werden und auch fixfertig wieder aus dem DAL kommen.

Dafür habe ich nun ein separates Assembly gebaut mit abstrakten Basisklassen für die Business-Objekte. Business Layer und DAL haben beide eine Referenz darauf, sodass beide die Grundstruktur der Objekte kennen. Hier eine schnelle PowerPoint-Skizze:

Der Business Layer kann nun dem DAL beliebige Instanzen von Klassen übergeben, welche von den (abstrakten) Basisklassen im DAL abgeleitet sind. Im Business Layer kann ich meine Business-Entitäten erstellen, die von den Basisklassen erben, meine Methoden erstellen und zusätzliche Interfaces implementieren, beispielsweise für bequemes .NET Windows Forms Data Binding.

Zur Implementierung habe ich vorerst nur die gekapselten Felder und das IEquatable Generic Interface in der Basisklasse implementiert: Die Entität soll grundsätzlich sofort einsetzbar sein (für Business-Layer und DAL!), aber keine besonderen Businessfunktionalitäten bereitstellen. Die braucht der DAL nämlich nicht, und hat sie auch nicht zu brauchen.

Nein, allzu neu ist die Idee nicht. Bei simple talk ist die Idee im Artikel “.NET Application Architecture: the Data Access Layer” (der Artikel ist sehr empfehlenswerte Lektüre!) beispielsweise aufgegriffen, diskutiert und Alternativen gegenübergestellt. Sie beschreibt diesen Approach als akademisch:

From an academic standpoint, this approach is probably the truest form of a data abstraction for a DAL because you can make the shared classes completely data-source independent and not just database independent.

Diesen Eindruck macht er auch auf mich. Ich bin mir nicht sicher, inwiefern er bei grossen Projekten mit aberhunderten von Entitäten wirklich bequem durchführbar ist. Aber er ist bestimmt nicht schlecht; ich werde damit experimentieren.

.NET Windows Forms Data Binding

In den nächsten Monaten steht mir Training in .NET bevor, um in näherer Zukunft die Prüfung zum Microsoft Certified Professional im Bereich .NET-Entwicklung (MCP 70-536) ablegen zu können. Gestern habe ich mich anhand von zwei Screencasts von Paul Stovell genauer mit DataBinding auseinandergesetzt. Der Post hat ein wenig TSchoenerNotizblock-Charakter und darf nicht als fertiger Artikel gesehen werden, das ist wichtig.

Implementierung von Business Objects

Für mein Beispiel, zugegebenermassen ein “gspürsch-mi?”-Beispiel, habe ich mir die Business-Entität “Person” ausgesucht, mit den Eigenschaften “FirstName”, “LastName” und “EMail” (exposed in gleichnamigen Properties). Zusätzlich habe steht ein Flag “IsDirty” bereit, das jedoch für mein Beispiel nicht von Bedeutung ist.

Ziel ist es, nach alter OO-Weisheit, das Objekt aus der echten Welt abzubilden. Diese Person allein könnte nun in .NET bereits als Datenquelle verwendet werden, jedoch habe ich einige weitere Implementationen vorgenommen, um die DataBinding-Features auszureizen.

IEditableObject, INotifyPropertyChanged, IDataErrorInfo

Meine Person-Klasse implementiert nun explizit (!) die .NET-DataBinding-Interfaces IEditableObject, INotifyPropertyChanged und IDataErrorInfo aus dem System.ComponentModel-Namespace. Die explizite Implementierung ist nicht zwingend, es funktioniert auch so. Ich habe den Ansatz gewählt, um das fachliche Element (die Entität “Person”) vom technischen Teil (DataBinding) der Klasse sauber zu trennen.

Ein Wort zur expliziten Interface-Implementierung: Implementiere ich ein Interface explizit, stehen die entsprechenden Properties nur zur Verfügung, wenn ich meine Objektinstanz in ein Feld vom Typ des Interfaces, in unserem Falle IEditableObject, INotifyPropertyChanged oder IDataErrorInfo speichere oder in ein solches caste. Habe ich ein Feld vom Typ Person, steht die Eigenschaft nicht zur Verfügung:

// Das Error-Property ist von IDataErrorInfo gegeben und
// implementiert.
Person p = new Person();
IDataErrorInfo d = new Person();
String s = p.Error(); // funktioniert nicht
String t = ((IDataErrorInfo)p).Error; // funktioniert
String u = d.Error; // funktioniert auch

Da nun .NET Windows Forms Data Binding intern mit den Interfaces arbeitet, kann es die Methoden und Eigenschaften, die wir bereitstellen, wunderbar verwenden. Arbeite ich jedoch selbst mit einer Objektinstanz, interessieren mich die DataBinding-Elemente nicht und ich sehe sie auch nicht. Wunderbar.

Die Implementierungen und deren Zweck rolle ich an dieser Stelle nicht aus. Gerne verweise ich auf die entsprechenden MSDN-Artikel oder den Screencast von Paul Stovell in seinem Blog-Post Binding Patterns 0×0002 - Binding to Objects (englisch) mit dem geilen Kamel. Das Video habe ich mir an einem gemütlichen Sonntag Morgen bei einem Käffchen und einer Schale Corn Flakes reingezogen und in vierzig gemütlichen Minuten viel gelernt (und mich gefragt, warum ich jahrelang von Hand Text-Boxen abgefüllt habe…).

Architektur

Diese Implentierung hält die Architektur der Programms sauber. Beispielsweise sind sämtliche Validierungsroutinen dank dem IDataErrorInfo-Interface innerhalb des Business-Objekts angesiedelt und wandern nicht in den Anzeige-Layer. Und weil .NET Windows Forms Data Binding diese Interfaces out-of-the-box unterstützt, ist auch die Fehleranzeige durch einfaches Einfügen eines ErrorProviders auf der Form, der an die BindingSource gehängt wird, getan.

Der Anzeige-Layer ist dank DataBinding wirklich nur ein Anzeige-Layer und beinhaltet keinen weiteren Code. Fehlerbehandlung, Editieren mit Abbrechen und Bestätigen sowie die Aktualisierung aller Fehler läuft automatisch.