Von der Datenbank bis zur Oberfläche mit .NET, Teil 5: Desktop- und Browseranwendung mit Silverlight

Inhaltsverzeichnis

Im vierten Teil des .NET-Tutorials entstand eine mit Windows Presentation Foundation erstellte Desktop-Anwendung. Diese soll nun in eine Silverlight-Anwendung überführt werden, die ebenso wie WPF die Auszeichnungssprache XAML verwendet. Silverlight-Programme laufen wahlweise in Webbrowsern oder auf dem Windows-Desktop.

Während die erste Version von Silverlight noch auf JavaScript beruhte, kommt seit Version 2.0 eine reduzierte Variante des .NET Framework zum Einsatz. Der Entwickler kann daher C# und Visual Basic .NET sowie viele der aus .NET bekannten Klassen verwenden. Silverlight ist in den Versionen 1.0 bis 5.1 in relativ kurzer Versionsfolge in den Jahren 2007 bis 2012 erschienen. Microsoft unterstützt mit Silverlight nicht nur Internet Explorer (ab 7.0), sondern auch Firefox (ab 3.6), Chrome (ab 12.0) sowie Safari (ab 4.0) auf Mac OS X.

Mehr Infos

Von der Datenbank bis zur Oberfläche mit .NET

• Teil 1: Datenzugriff und Logik
• Teil 2: Application Server und Webservices
• Teil 3: Webanwendung mit ASP.NET
• Teil 4: Desktop-Anwendung mit WPF
• Teil 5: Desktop- und Browseranwendung mit Silverlight

Um das Beispiel mitzuprogrammieren, benötigt der Entwickler Grundkenntnisse in der C#-Syntax und der Handhabung von Visual Studio 2010. Das Tutorial verwendet die englische Version von Visual Studio, weil es in der deutschen Ausgabe einen Fehler gibt, durch den sich das Beispiel nicht ohne viel manuelle Arbeit zum Laufen bringen lässt.

Den Quellcode zum Artikel findet man hier.

In den letzten Monaten wurde wiederholt berichtet, dass Microsoft nun seine Begeisterung für Silverlight verloren habe und nun Oberflächen mit HTML5 und JavaScript favorisiere. Die Anwendergemeinde vermutet, dass Microsoft nach Silverlight 5 keine neue Hauptversion mit weiteren signifikanten neuen Features mehr produzieren werde. Das letzte Wort ist aus Redmond dazu aber noch nicht gesprochen, auch wenn es Anzeichen gibt, dass Microsoft sich selbst bei eigenen Produkten (z. B. dem Windows Azure Management Portal und Visual Studio LightSwitch) von Silverlight verabschiedet.

Dennoch hat Silverlight (zumindest vorerst) weiterhin einen Platz im Portfolio der Webentwickler, denn (noch) ist die Arbeit mit Silverlight wesentlich produktiver als mit HTML5 und JavaScript. Die hohe Produktivität von Silverlight beruht vor allem auf der Verwendung der klassenbasierten, streng typisierten Sprachen C# und Visual Basic, der reichhaltigen Silverlight-Klassenbibliothek sowie der mächtigen Entwicklungsumgebung Visual Studio mit viel Eingabeunterstützung und Validierung zur Kompilierzeit.

Zudem gibt es bei Silverlight keine Herausforderungen mit der Browserkompatibilität. In jedem Browser, in dem die Silverlight-Laufzeitumgebung als Plug-in installiert ist, läuft Silverlight gleich. Das Problem ist freilich, dass bei weitem weniger Benutzer die Silverlight- als die Flash-Laufzeitumgebung in ihrem Browser installiert haben. Silverlight ist daher vor allem eine gute Wahl für Intranets und gegebenenfalls Extranets, in denen man die Installation des Silverlight-Plug-ins durchführen beziehungsweise durchsetzen kann, aber keine gute Wahl für das öffentliche World Wide Web. Es gab eine Portierung von Silverlight auf Unix/Linux unter dem Namen Moonlight, die aber inzwischen eingestellt ist.

Zum Entwickeln mit Silverlight 5.1 muss man neben Visual Studio (Variante Professional, Premium, Ultimate oder Visual Web Developer Express) zunächst die Silverlight Tools for Visual Studio und das Silverlight Toolkit installieren, das zusätzliche Steuerelemente enthält. Es gibt andere Erweiterungspakete für Silverlight, zum Beispiel Silverlight Contrib, die aber hier nicht zum Einsatz kommen.

Dann ist eine neue "Silverlight Application" mit Namen "WWWings_SL" in der bestehenden Projektmappe "WWWings.sln" anzulegen. Beim Anlegen erscheint der Dialog in Abbildung 1.

Darin gilt es, ein Webserverprojekt festzulegen, dass eine HTML-Seite bereitstellt, in die die Silverlight-Anwendung geladen wird. Man könnte dafür ein neues Webserverprojekt anlegen; hier soll aber WWWings_Web verwendet werden, das in Teil 3 des Tutorials für die ASP.NET-Anwendung entstanden ist. Silverlight und ASP.NET können in einem Webprojekt koexistieren und bei Bedarf über AJAX auch interagieren. In WWWings_Web entsteht diese HTML-Seite in zwei Varianten: Als reine HTML-Seite (WWWings_SLTestPage.html) und als ASP.NET-Webseite (WWWings_SLTestPage.aspx). Einen funktionalen Unterschied gibt es zunächst nicht. Das Silverlight-Projekt wird in eine ZIP-Paket mit Dateinamenserweiterung .aspx (WWWings_SL.xap) verpackt und während des Kompiliervorgangs in das Webprojekt WWWings_Web in den Ordner "ClientBin" kopiert. Die beiden Seiten WWWings_SLTestPage.html und WWWings_SLTestPage.aspx binden das .xap-Paket über ein <object>-Tag ein:

<object data="data:application/x-silverlight-2," type="application/
        x-silverlight-2" width="100%" height="100%">
<param name="source" value="ClientBin/WWWings_SL.xap"/>
<param name="onError" value="onSilverlightError" />
<param name="background" value="white" />
<param name="minRuntimeVersion" value="5.0.61118.0" />
<param name="autoUpgrade" value="true" />
<a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=5.0.61118.0" 
        style="text-decoration:none">
<img src="http://go.microsoft.com/fwlink/?LinkId=161376" alt="Get Microsoft 
        Silverlight" style="border-style:none"/>
</a>
</object>

Außerdem findet man in den beiden Seiten ein wenig JavaScript (Routine onSilverlightError), das Fehlermeldungen von Silverlight an den Browser weiterreicht.

Nach einem Kompilieren der Lösung und dem Starten der Testseite im Browser (Kontextmenü View in Browser) sollte jeweils eine leere Webseite mit einem eingebetteten leeren Silverlight-Fenster erscheinen. Ein Klick des Anwenders auf die rechte Maustaste im Browserfenster wird durch den Eintrag "Silverlight" im Kontextmenü beweisen, dass tatsächlich Silverlight im Spiel ist. Aus kosmetischen Gründen soll hier WWWings_SLTestPage.html in SilverlightApp.html umbenannt werden. Um das Debugging von Visual Studio zu nutzen, muss man WWWings_Web als Standardprojekt (Set as StartUp Project) und die Seite SilverlightApp.html als Startseite (Set as Start Page) festlegen.

Neue Bibliotheken für Silverlight

Nun müsste man wie beim ASP.NET- (Teil 3) und WPF-Client (Teil 4) die gemeinsamen Objekte (WWWings_GO) und die Dienst-Proxies (WWWings_Dienstproxies) referenzieren im Silverlight-Projekt. Allerdings geht das in diesem Fall nicht so einfach, denn aus einem Silverlight-Projekt heraus kann man nicht Projekte einbinden, die für das fertige .NET Framework kompiliert wurden. Möglich wäre das nur, wenn man ursprünglich eine "Portable Library" angelegt hätte. Das hätte aber andere Herausforderungen mit sich gebracht.

Der Entwickler muss für Silverlight nun zwei neue Bibliotheken anlegen: WWWings_SLGO und WWWings_SLDienstproxies. Vorlage ist dabei "Silverlight Class Library". Die erste Bibliothek kann dabei den gleichen Code enthalten wie WWWings_GO, allerdings nicht das Entity-Framework-Modell (.edmx-Datei). Namentlich zu übernehmen sind also die generierten Entitätsklassendateien (Flug.cs, Passagier.cs, Person.cs und Pilot.cs), die manuellen Erweiterungen der Entitätsklassen (EntitaetsklassenErweiterungen.cs) und die Dienstdefinition (Dienstschnittstellen.cs und Nachrichtenklassen.cs). Statt die Dateien zu kopieren, sollte der Entwickler sie verknüpfen, damit sie bei Änderungen auch automatisch wirken. Eine Verknüpfung erstellt er in Visual Studio mit Add existing Item und dann Add as link. Verknüpfte Dateien erkennt er an einem kleinen Pfeil im Dateisymbol im Projektmappen-Explorer von Visual Studio. Die WWWings_SLDienstproxies muss er neu erzeugen, denn die Dienst-Proxies des .NET Framework sind nicht kompatibel mit Silverlight. Der Entwickler legt also ein Projekt WWWings_SLDienstproxies an und erzeugt über Add Service Reference die Proxies neu, so wie in Teil 2 des Tutorials beschrieben. Anders als bei WWWings_Dienstproxies landet die XML-Konfiguration nicht in der Datei app.config, sondern in ServiceReferences.ClientConfig.

Nach dem Erstellen der beiden Bibliotheken legt der Entwickler aus dem Silverlight-Projekt WWWings_SL Verweise auf die Projekte WWWings_SLDienstproxies und WWWings_SLGO-Bibliothek sowie die System.ServiceModel-Bibliothek an. Zudem muss er die Datei ServiceReferences.ClientConfig aus dem Projekt WWWings_SLDienstproxies in das Projekt WWWings_SL kopieren, da dort Adresse und Konfigurationsinformationen für den Zugriff auf die Webservices abgelegt sind. Die Datei ServiceReferences.ClientConfig entspricht dem in Teil 3 und 4 erfolgten Übernehmen der app.config-Datei.

Nun reicht das aber immer noch nicht. Man muss in das Projekt "WWWings_Server", das die Webservices bereitstellt, noch die Datei crossdomain.xml mit dem folgenden Inhalt im Wurzelverzeichnis ablegen.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/
       dtds/cross-domain-policy.dtd">
<cross-domain-policy>
 <allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

Der Grund dafür ist eine Standardsicherheitsbeschränkung: Die Silverlight-Anwendung wird über das Projekt WWWings_Web vom Port 82 geladen. Die Webservices werden über WWWings_Server aber auf Port 81 gehostet. Wenn crossdomain.xml nicht erlaubt, dass die Webservices von fremden Websites aufgerufen werden, kommt es beim Aufruf zum Fehler: "Fehler beim Senden einer Anforderung an den URI "http://localhost:81/BuchungsService.svc". Ursache ist möglicherweise, dass ohne die entsprechende domänenübergreifende Richtlinie oder mit einer nicht für SOAP-Dienste geeigneten Richtlinie domänenübergreifend auf einen Dienst zugegriffen wurde."

Endlich ist die Architektur fertig aufgebaut, und es lässt sich mit dem Realisieren der Fenster beginnen. Die Architektur stellt Abbildung 2 grafisch dar, wobei hier auch die Views und di e ViewModels eingezeichnet sind, die im Folgenden entstehen.