Seite 4: Funktionen

Inhaltsverzeichnis

Schichtenmodell und Verbreitung

Die LightSwitch-Oberfläche ist immer eine Silverlight-Anwendung, der Entwickler hat jedoch Einfluss darauf, ob die Anwendung direkt auf dem Desktop (mit vollständigem .NET Framework) oder im Browser (als Silverlight-Plug-in) läuft und wie sie die Daten bezieht. Standard ist der Modus "Desktop client, 2-tier Deployment". Das bedeutet, dass Silverlight direkt auf die Datenbank zugreift. Im Modus "Desktop client, 3-tier Deployment" laufen alle Datenbankzugriffe über Webservices auf einem Internet Information Server (IIS). Weiterhin ist ein Hosting in Microsofts Cloud-Dienst "Windows Azure" möglich.

Im dritten Modus "Browser client, 3-tier Deployment" ist der Zugriff über Webservices die einzige Wahl. Zur Entwicklungszeit wird ein IIS nicht benötigt. LightSwitch verfügt genau wie das große Visual Studio über einen integrierten lokalen Webserver, der hier "LightSwitch Server" heißt und sich als Benachrichtigungssymbol in der Taskleiste bemerkbar macht, wenn man das Debugging startet. Beim Start im Browser läuft die LightSwitch-Anwendung in einer Sandbox; Dateisystemzugriffe und Excel-Export sind dann verboten. Die erste Version von LightSwitch wird noch nicht auf Windows Phone 7 laufen.

Über einen "Publishing Wizard" (Menü "Build/Publish") erzeugt man ein Installationspaket für die Verbreitung der Anwendung. Im Fall des "2-tier Deployment" entsteht eine setup.exe, die gegebenenfalls vorher das .NET Framework 4.0 und die zusätzlichen LightSwitch-Komponenten (optional auch einen SQL Server Express) von einem Microsoft- oder einem eigenen Server lädt und installiert. Für das "3-tier Deployment" entsteht hingegen ein MSDeploy-Paket für den IIS. Die SQL-Skripte zur Einrichtung der Datenbank sind in den Installationspaketen enthalten.

Weitere Funktionen

LightSwitch bietet noch weitere Funktionen, vondenen einige kurz erwähnt sein sollen:

• Der Entwickler kann Programmcode schreiben, der auf der Ebene der Entitäten und Abfragen in den Datenquellen eingreift, zum Beispiel beim Validieren, Speichern, Ändern oder Löschen. Meist gibt es ein Methodenpaar: eine Methode bei Beginn der Aktion (etwa Deleting) und eine nach ihrem Ende (Deleted). Über eine "Can"-Methode (beispielsweise CanDelete) kann der Entwickler außerdem bestimmen, ob eine Aktion überhaupt zugelassen ist.
• Über das allgegenwärtige Objekt "DataWorkspace" kann man in dem sowohl in Datenquellen als auch Bildschirmen hinterlegten Programmcode auf die Objektkontext-Klassen aller Datenquellen zugreifen und auf die Weise per Programmcode alle Aktionen ausführen (zum Beispiel das Schreiben der Protokolleinträge bei Aktionen des Benutzers).
• In den Projekteigenschaften kann der Entwickler eine Benutzeroberflächensprache festlegen. Bei der Beta 1 richten sich viele, aber nicht alle Standardsteuerelemente nach der Einstellung. Es sind nur die Sprachen Englisch, jJapanisch, Deutsch und Arabisch verfügbar. Die Spracheinstellung ist in die Anwendung hineinkompiliert. Für die erste Version plant Microsoft leider keine Umstellung der Sprache innerhalb der Anwendung.
• Eine Authentifizierung in der Anwendung ist über die Windows- (Single Sign-On) oder die aus ASP.NET bekannte "Forms"-Authentifizierung umsetzbar. Auf der Serverseite kommen dann das Benutzer- und das Rollenverwaltungssystem von ASP.NET zum Einsatz, auch wenn kein "3-tier deployment" gewählt wurde. In der ApplicationDatabase.mdf findet man dazu bekannte Tabellen wie aspnet_Users, aspnet_Roles und aspnet_Profile.
• Die generierte Anwendung besitzt zwei vordefinierte Bildschirme: "Users" und "Roles". In Letzterem kann man Rollen anlegen und ihnen Rechte zuweisen, die man vorher in den Projekteigenschaften festgelegt hat. Unter "User" kann man Benutzer anlegen und Rollen zuordnen. Im Programmcode (etwa in den Routinen, die mit "Can" beginnen, zum Beispiel CanExecute() oder CanDelete()) lässt sich jederzeit prüfen, ob der aktuelle Benutzer ein Recht besitzt, beispielsweise Current.User.HasPermission(AdminRechte). In den Projekteigenschaften kann der Entwickler festlegen, welche Rechte beim Debugging aktiv sein sollen.
• Den von LightSwitch generierten Programmcode kann man auf der Festplatte betrachten. Das LightSwitch-Projekt hat die Dateinamenserweiterung lsproj. Zentraler Speicherort für alle Einstellungen zu Datenquellen, Bildschirmen, Navigation und Authentifizierung ist die XML-Datei ApplicationDefinition.lsml im Unterordner "Data". Eine einfaches Mittel zur Erforschung der Hintergründe ist auch die Nutzung der Funktion "Go to Definition" in der Entwicklungsumgebung. Wenn man das Kontextmenü, zum Beispiel "public partial class Personenliste", im Bildschirm "Personenliste" ausführt, gelangt man zu mehr als 1000 Zeilen generierten Programmcodes.
  

Was sicherlich in LightSwitch bisher fehlt und zudem nicht mehr für die erste Version geplant ist, sind Berichte. Das ist natürlich eine wesentliche Einschränkung. Microsoft rechnet aber damit, dass Drittanbieter diese schmerzliche Lücke füllen werden. Ein Blog-Eintrag zeigt, wie man aus LightSwitch heraus den Inhalt von Bildschirmen und Steuerelementen mit derKlasse PrintDocument drucken kann. Auch die spezielle Unterstützung für Caching im Offline-Zustand fehlt noch.