Visual Studio LightSwitch unter der Lupe

Seite 2: Projektstart & Datenbankanbindung

Inhaltsverzeichnis

Nach dem LightSwitch-Begrüßungsfenster sieht man beim Start zunächst eine vertraute Visual-Studio-2010-Oberfläche. Dass man in einer anderen Welt ist, zeigt sich aber beim Anlegen eines neuen Projekts: Statt der Qual der Wahl zwischen Dutzenden Vorlagen steht der Anwender nur vor der Entscheidung C# oder Visual Basic (siehe Abbildung 1).

Projektauswahl zwischen einer C#- und einer Visual-Basic-Anwendung (Abb. 1)

Positiv fällt die Option "Add to Source Control" auf. LightSwitch unterstützt Versionsverwaltung von Hause aus mit dem Team Foundation Server (TFS). Ein Dialog zur Auswahl anderer Quellcodeprovider ist in den Optionen vorhanden.

Nach dem Anlegen eines Projekts sieht man im Solution Explorer drei leere Ordner (Properties, Data Sources und Screens), und in der Bildschirmmitte hat der Anwender die Wahl, eine neue Datenbank anzulegen oder eine bestehende zu verwenden (siehe Abbildung 2).

Ein leeres LightSwitch-Projekt (Abb. 2)

Wer sich das angeblich leere Projekt auf der Festplatte ansieht, erkennt den Charakter von LightSwitch: Es sind fünf Visual-Studio-Quellcodeprojekte und diverse BIN-Ordner sowie eine leere Datenbank (ApplicationDatabase.mdf) entstanden – insgesamt 618 Dateien in der Größe von 68,5 MByte. Wenn man nun schon auf "Starten" klickt, sieht man ein Fenster mit einer leeren Menüleiste links und leerem Inhaltsbereich. Ein Blick in das Kontextmenü verrät: Es handelt sich um eine Silverlight-Anwendung, die man in dem Fall außerhalb des Browser gestartet hat.

Unter "Attach to external database" findet man als Quellen neben dem SQL Server (einschließlich SQL Server Express und SQL Azure) als Optionen SharePoint und einen WCF-RIA-Service, sodass auch eine Anbindung an bestehende Anwendungen möglich ist. Für eine SQL-Server-Datenbank bietet die IDE die Auswahl von Tabellen und Sichten an, nicht aber Stored Procedures. Am Ende des Assistenten zeigt die Entwicklungsumgebung die ausgewählten Tabellen im Solution Explorer unter Data Sources an.

Die Namen mögen auf den ersten Blick verwundern: LightSwitch hat an die Tabellennamen ein "s" angehängt, aus "Flug" wurde "Flugs", aus "Mitarbeiter" wurde "Mitarbeiters" und aus "Person" wurde "People". Eingeweihte wissen, dass dabei der Pluralisierungsdienst des ADO.NET Entity Framework 4.0 am Werke war. Während in der vollständigen Version von Visual Studio der Entity-Framework-Assistent die Pluralisierung als Option anbietet, ist sie in der Beta 1 von LightSwitch immer aktiv und eine Option zum Abschalten auch nach intensiver Suche nicht auffindbar. Immerhin kann man nachträglich im Designer die unschönen Pluralbildungen manuell ändern. Man kann dabei Singular und Plural gleich benennen; die Pluralbildung macht nur den Code etwas übersichtlicher. Der Autor des Beitrags empfiehlt, dass prägnante Wort "Set" (oder deutsch: "Menge") anzuhängen, aus "Person" wird so "PersonSet" beziehungsweise "PersonMenge".

Die Designer-Ansicht der erzeugten Entitäten ist anders als im großen Bruder: Anstelle einer endlosen Zeichenfläche mit Zoom sieht man immer nur eine Entität mit ihren direkten Beziehungen. Die Liste der Einstellungen für jede Spalte ist einerseits einfacher gehalten als im Entity-Framework-Designer in Visual Studio 2010 (beispielsweise ist statt "Allow Nulls" die Frage hier "Required"), zum anderen gibt es aber die Option, Einfluss auf die Benutzeroberfläche nach einem modellgetriebenen Ansatz zu nehmen. Zu jedem Feld lässt sich festlegen, ob es auf dem Bildschirm erscheinen und wie es dort heißen soll (Display-Name) beziehungsweise ob es durchsuchbar ist. Bei Zeichenketten kann man eine Maximallänge vorgeben und bei Datum- und Zahlfeldern einen Wertebereich. Über "Choice List" lassen sich direkt mögliche Werte definieren. Pro Entität darf man außerdem einen "Default Screen" einstellen, was aber noch keinen Sinn ergibt, solange man keine Bildschirme erstellt hat.

Einbinden einer bestehenden Datenbank (Abb. 3)

Berührung mit einem Code-Editor erhält man durch einen Klick auf "Custom Validation". Es erscheint der bekannte Visual-Studio-Editor (mit allen zentralen Funktionen wie IntelliSense, Refactoring, Code-Schnippseln und Haltepunkten), um eine beliebige Validierungslogik zu hinterlegen. Ein Beispiel in C# wäre:

partial void Geburtstag_Validate(EntityValidationResultsBuilder 
results)
{
if (this.Geburtstag.HasValue && ((DateTime.Now<this.Geburtstag.Value))
results.AddPropertyError("Geburtstag kann nicht in der Zukunft liegen!");
}

Die zu verwendende Sprache (C# oder Visual Basic) hängt von der Projektauswahl zu Beginn ab.

Eine Tabelle hinzufügen darf man der bestehenden Datenbank im Solution Explorer nicht. Die Option "Add Table" ist ausgegraut. Hierfür muss man derzeit auf den aus dem großen Visual Studio bekannten Server Explorer (beziehungsweise Database Explorer in den Express-Editionen) zurückgreifen und dort die Tabelle direkt im SQL Server anlegen. Anschließend kann man die Tabelle über "Refresh Datasource" in LightSwitch einbinden.

Die Funktion "Add Table" gibt es zwar über den Ast "Data Source" im Solution Explorer, hierdurch entsteht aber eine Tabelle in der erwähnten Datenbank ApplicationDatabase.mdf. Als Datentypen hat man die .NET- anstelle der SQL-Server-Datentypen zur Auswahl. Darüber hinaus gibt es mit "EmailAddress" und "PhoneNumber" noch zwei Spezialisierungen von "String" mit automatischer Validierung sowie "Money" als Spezialisierung von "Decimal".

Auch der Dialog zum Anlegen von Beziehungen (Schaltfläche "Relationship" oder Kontextmenü "Add Relationship") erinnert an Access. Zusätzlich zur Angabe der Kardinalitäten in formaler Schreibweise zeigt die Entwicklungsumgebung eine Erläuterung in Textform. Überraschenderweise kann man zudem datenbankübergreifende Beziehungen anlegen (siehe Abbildung 4). Sie bildet LightSwitch aber nicht in der Datenbank, sondern rein auf Anwendungsebene ab.

Erstellen einer neuen Tabelle mit Beziehungen - auch zu anderen Datenbanken (Abb. 4)

"Add Query" erlaubt, innerhalb des Solution Explorer im Kontextmenü einer Entität eine Abfrage mit Filter, Sortierung und Gruppierung zu gestalten. Leider gibt es ebenso wie bei den Entitäten auch bei den Abfragen keine Vorschau auf die Daten. Auch ein Join über mehrere Entitäten ist noch nicht im Abfragedesigner umzusetzen. Dafür bleibt die Option, direkt in der Datenbank Sichten zu definieren und diese in LightSwitch einzubinden. Es besteht also noch Vereinfachungspotenzial. Sofern die Abfrage zwar einen Join enthält, aber wieder nur Datensätze des Abfragetyps liefert, kann man in dem Ereignis PreprocessQuery (zu finden über die Schaltfläche "Write Code", siehe Abbildung 5) eine komplexere Abfrage per Code definieren.

Abfrage definieren (Abb. 5)