LightSwitch – Genauer hingeschaut Teil 1 (Teil 2)
Kommentare

Der nächste logische Schritt ist es nun, eigene Abfragen zu definieren. Den Großteil der Anforderungen konnte Microsoft wiederum per Designer abdecken – und es ist wirklich ein Leichtes, eine Abfrage

Der nächste logische Schritt ist es nun, eigene Abfragen zu definieren. Den Großteil der Anforderungen konnte Microsoft wiederum per Designer abdecken – und es ist wirklich ein Leichtes, eine Abfrage per Designer zu generieren. Im vorliegenden Beispiel wird eine Abfrage definiert, die alle Abteilungen auflistet, in denen ein Abteilungsleiter mit dem Nachnamen Sinclair regiert (dies betrifft nur die Abteilung Personnel). Abbildung 4 zeigt die Erstellung dieser rudimentären Abfrage HeadSinclair. Nach ihrer Erstellung finden Sie die Abfrage auch im Solution Explorer in der Projektstruktur unter APPLICATION DATA | DEPARTMENTS | HEADSINCLAIR wieder.

Abb. 4: Die Abfrage
Abb. 4: Die Abfrage „HeadSinclair“ im Designmodus

Die genannte Abfrage können Sie beispielsweise bei der Erstellung neuer Screens unter Data auswählen; sie sollte erwartungsgemäß als Resultat die Abteilung Personnel, zusammen mit deren Leiter John Sinclair liefern (Abb. 5).

Abb. 5: Search Screen, der die Abfrage
Abb. 5: Search Screen, der die Abfrage „HeadSinclair“ verwendet

So weit, so gut. Wir haben nun ein Datenmodell, einige Screens zur Eingabe und Anzeige der Daten, einige Testdaten und auch bereits eine erste Abfrage per Designer erstellt und deren Resultate visualisiert. Dies entspricht immer noch der von Microsoft intendierten Standardvorgehensweise für die Erstellung von LightSwitch-Applikationen. Sie werden sicherlich die zahlreichen Möglichkeiten bemerkt haben, die Microsoft zur designerbasierten Erstellung von Abfragen bereitstellt: 

  • Filter (nach mehreren Feldern, Anwendung logischer Operatoren, Anwendung verschiedener Vergleichsoperatoren)
  • Sortierung (nach mehreren Feldern, Definition der Reihenfolge und der Sortierrichtung)
  • Parameter (mit Typangabe, auch komplexe Typen sind erlaubt)

Die genannten Möglichkeiten können im Designer bequem per Mausklick bedient werden und so mit wenigen Handgriffen zu relativ aussagekräftigen Abfragen führen, die für den Normalfall völlig ausreichend sind. Aber wie so oft stellt eine Vereinfachung und Abstraktion der Dinge auch gleichzeitig eine Limitierung dar. Mit anderen Worten: Sie können viel mit dem Abfragedesigner formulieren, aber eben nicht alles. Ein Beispiel ist die Verwendung von Aggregatfunktionen: Diese können per Designer nicht eingesetzt werden, um beispielsweise Abfrageergebnisse einzuschränken. Damit man bei der Businessanwendung hier nicht auf Grenzen stößt, hat Microsoft vorgesorgt und erlaubt die codegesteuerte Erweiterung von Abfragen.

Im folgenden Beispiel soll die Abfrage HeadSinclair so erweitert werden, dass sie nur Resultate liefert, wenn die Anzahl der Abteilungen, in denen tatsächlich Sinclair der Leiter oder einfach nur Mitarbeiter ist, größer als ein selbst definierter Wert ist (sinnig wäre der Wert 1, aber für die Demonstration des Beispiels soll ein variabler Wert angenommen werden). Damit der Parameter auch im Code verwendet werden kann, muss im Abfragendesigner zunächst ein benannter Parameter definiert werden. Dies geschieht ebenfalls mit wenigen Handgriffen. Erweitern Sie die Abfrage so wie in Abbildung 6. Die Abfrage funktioniert weiterhin. Sie haben nur definiert, dass es einen Parameter namens MinDepartments geben könnte; zum Einsatz gekommen ist er aber noch nicht.

Abb. 6: Die um
Abb. 6: Die um „MinDepartments“ erweiterte Abfrage „HeadSinclair“
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -