Zunächst zum Thema “Grundsatzdiskussion”: Ich persönlich bin kein großer Freund dieser Form von Diskussionen, werden sie doch gerne anhand von vereinfachten Beispielen geführt und nähern sich schnell einem recht grundlegendem Level an, da ab einem gewissen Punkt das Selbstverständnis eines Teils der Diskussionspartner berührt werden könnte. Das beiseite gelassen, eignen sie sich jedoch wundervoll, um unterschiedliche Grundideen auszuarbeiten, wie es in diesem Fall geschehen ist: Auf der einen Seite die Fraktion, die gerne auf null als Rückgabewert von GetXXX-Funktionalitäten verzichten möchte, wenn diese als Parameter einen ID-Wert übergeben bekommen und der Datensatz nicht existiert (Begründung: ID kennzeichnet nun mal einen eindeutig identifizierten Datensatz, gibt es diesen nicht, ist irgendwas faul im Staate Dänemark – das Ganze kann dann wahlweise über ein Null-Objekt oder eine Exception abgebildet werden), auf der anderen Seite die Fraktion, die in diesem Fall eben null zurück gibt und das im Code abfragen und abfangen möchte.

Unabhängig davon, dass ich die Meinungen beider Fraktionen nachvollziehen kann (und dennoch gerne Null-Objekte einsetze, da sie die weitere Verarbeitung stark erleichtern können und oftmals der Wartbarkeit zuträglich sind), haben wir es hier mit einem eher grundsätzlicheren Problem zu tun: Clean Code vs. pragmatische Entwicklung, um es mal zugespitzt zu umschreiben. Dieser Widerspruch ist jedoch bei näherer Betrachtung keiner, jedenfalls soweit es mich betrifft, denn in Wahrheit haben wir es an dieser Stelle eher mit zwei verschiedenen Anforderungsmodellen zu tun:

Beiden Fraktionen geht es um einen möglichst sauberen, wiederverwendbaren und auch für andere Entwickler leicht verständlichen Code. Da sind sich beide einig, der Unterschied liegt darin, ob und wie mit Annahmen außerhalb des DataLayers umgegangen wird:

• Die “Clean Coder” wollen, dass der Code vertrauenswürdig ist, d.h. er soll sich in jedem Fall eindeutig verhalten und außerhalb des Kontextes etwa eines DataLayers keinerlei Annahmen über dessen Struktur und Funktionsweise erfordern. Ich folge diesem Ansatz in der Regel. Das bedeutet für: Null-Objekte, da wo es sinnvoll ist (Benutzer gehören für mich in aller Regel dazu), null bei nicht relevanten Geschichten oder Dingen, die schon ganz eindeutig aussagen, dass es eventuell auch KEIN Ergebnis geben kann (FindXXX-Methoden wäre klassische Kandidaten dafür).
• Die “Pragmatiker” haben einen anderen Schwerpunkt: Sie legen weniger Wert auf die oben angesprochene Vertrauenswürdigkeit von Code, denn die erarbeiteten Lösungen werden entweder meist allein verwendet, oder stellen Lösungen dar, die von einem Endkunden in aller Regel nicht selbstständig weiterentwickelt werden. Hier heißt es: Null statt eines Null-Objekts, denn hier ist außen bekannt, wie das Repository sich verhält und die Anwendungsfälle für etwa Null-Objekte halten sich meist in Grenzen.

Beide Fraktionen haben somit unterschiedliche Anforderungen an Code, der scheinbare Widerspruch zwischen pragmatischem und sauberen Programmieren ist also keiner – wir haben es schlicht mit unterschiedlichen Verwendungsszenarien zu tun.

Ob, und in welchem Umfang man nun die Meinung der einen oder der anderen Fraktion teilen mag, ist eine andere Frage. Ich persönlich tendiere zur Clean Code-Ansicht, denn ich habe für mich die Sinnhaftigkeit von Null-Objekten schon seit geraumer Zeit erkannt. Dementsprechend definiere ich meine Entitäten und meine Schichten auch und kann mich so darauf verlassen, stets eine funktionsfähige Objektinstanz zu besitzen und entsprechend meinen Code einfacher strukturieren. Das Ergebnis: Wartbarkeit und Sicherheit steigen, meine Applikation verhält sich vorhersagbarer, ich kann mindestens ebenso gut testen, wie beim eher “pragmatischen” Ansatz.

Insofern erscheint mir hier der Clean Code-Ansatz im Endeffekt sogar pragmatischer zu sein.

Hier nun die letzten Fakten zu Windows Phone 7 Series, die ich – wie die letzten Male auch – direkt wieder aus meiner Twitter-Timeline klaue:

• Performance beginnt schon beim Designer. Nicht erst beim Entwickler.
• Fixed Width / Fixed Height bei Listen ist derzeit optimal. Data Virtualization (lade nur das, was Du brauchst).
• 30 Frames / Sekunde für Animationen / Video / etc.
• Application.Current.Host.Settings.EnableFrameRateCounter – kann genutzt werden, um Performance zu messen.
• Application.Current.Host.Settings.EnableRedrawRegions – Feststellen, was wann wie wo neu gezeichnet werden muss.
• BitmapCache einschalten steigert Performance.
• Gerade die Animationen können extrem performancehungrig werden. Sollte man sich tatsächlich mal in Ruhe irgendwo anschauen.
• CacheModes sollten nicht gemischt werden – CacheMode="None" innerhalb von CacheMode="BitmapCache"-Elementen ist extrem unperformant.
• Media mit geringstmöglicher Framerate codieren – sehr aufwändig zu rendern.
• Auch bei MediaElement: CacheMode="BitmapCache" setzen.
• Media-Decoding + PNG-Handling stets hardwarebasiert, JPG-Handling KANN hardwarebasiert stattfinden.
• Hardware-Beschleunigung nur für Elemente bis max 2.048×2.048 Pixeln. Alles, was größer ist, muss per Software "beschleunigt" werden.
• Wichtig: Applikationen laufen nur mit gültiger License
• Code ist signiert
• Applikationen können nur Ressourcen ansprechen, für die sie freigegeben sind, wird zur Laufzeit überprüft.
• Klare Aussage: "Echte Programme" (C++) wird es nicht auf der Plattform geben.
• Push-Notification-Tokens bleiben auch beim Pausieren gültig. App muss sich also noch dem Pausieren nicht neu registrieren.
• Keine DLLs übers Netz nachladbar. Nur signierter Code wird ausgeführt. Signierter Code kommt nur über den Marketplace.
• Find & Wipe-Remote-Service existiert.
• MyPhone-Service setzt Find & Wipe-Remote-Service um
• Updates für das Gerät werden von MS bereitgestellt, es wird aber keine Patch-Tuesdays geben. Also eher analog zu #iPhone.
• Marketplace kann mehr, als bisher bekannt – es wird wohl Szenarios rund um geschlossene Benutzergruppen o.ä. geben.
• Featured-App kontrolliert den Hintergrund des Marketplaces.
• Suche funktioniert natürlich auch im Marketplace.
• Apps in der Regel innerhalb von 5 Tagen verfügbar, klare Aussagen über Timelines, Dokus ab Mai für Windows Phone aktualisiert.
• Applikation wird von Microsoft auf benötigte Schnittstellen geprüft und mit einem Manifest versehen.
• Applikationen / Käufe sind an die Live-ID gebunden, bis zu fünf Geräte parallel mit einer ID einsetzbar.
• Kein Nexus von Microsoft geplant. MS verkauft weiterhin keine Entwickler-Phones.
• Kein Buy once – Play everywhere (XBox-Spiel kaufen und auf WP7S spielen) derzeit, vielleicht zukünftig.
• XNA ist C#-only, Managed Code only.
• Silverlight: Wenn Vektorgrafiken, XNA: Wenn 3D-Grafiken. Mal ganz pauschal gesagt.
• Konfigurierbare Standardeffekte, keine Custom Shaders. #XNA
• Zugriff auf Audio, Video und Photos via #XNA-Framework. Nicht nur Chooser notwendig, wenn ich das richtig verstanden habe.
• Zwei Profile bei #XNA: Reach (möglichst kompatibel für alle Plattformen) oder HiDef (spezifisch nur für eine Plattform).
• Derzeit nur Entwicklung mit C#. VB kommt (vielleicht) später nach. #MIX10
• Allgemein: class statt struct, struct nur für Dinge, die kleiner 16 Bytes sind
• GC ist teuer. Zwei Strategien: Seltener laufen lassen (Objekte < 1MB). Oder: Schnell fertig werden lassen (ValueTypes verwenden).
• GC: Weniger Referenzen. Nur Objekte, wo notwendig. Weniger Listen, mehr Arrays.
• GC manuell aufrufen: GC.Collect() – bitte nicht so oft. Teuer. Idealerweise nur nach dem Load oder in Pausen.
• Boxing vermeiden. StringBuilder statt String. GC per WeakReference-Klasse überprüfen. CLR-Profiler verwenden (#XNA). .NET Reflektor.
• foreach-Statement ist okay, darauf achten, dass der Enumerator ein primitiver Typ ist.
• yield-Statement verwenden – wird zu einem Zustandsautomaten kompiliert.
• Best practices für mobiles Web: Weniger Farben und Schriften, weniger JS, keine Backgrounds, Content an Screengröße anpassen. Kleine Bilder.
• Best practices für mobiles Web (II): So wenig als möglich Input, sinnvolle Vorgaben, Cookies für Eingaben verwenden.
• Entwicklung für mobiles Web: Standards verwenden (XHTML, HTML 4.01, XHTML-MP), CSS 2.1, DOM 1, ECMAScript3. DOCTYPE setzen.
• Entwicklung für mobiles Web: Standard-Medientypen (JPEG, GIF, PNG, 3GP, AVI, WMV, MP4) verwenden. Keine Frames!
• Entwicklung für mobiles Web: Keine Table-Layouts, keine nested Tables, keine Image-Maps, kein Flash.
• Entwicklung für mobiles Web: Mobile-META-Tags verwenden: HandheldFriendly, MobileOptimized, Viewport.
• Standard-Viewport für #WP7S: 1024px.
• Entwicklung für mobiles Web: JS im Client für Fähigkeiten verwenden, UserAgent auf dem Server nutzen
• Entwicklung für mobiles Web: Bei Codeplex mal nach #MBDF schauen – UserAgents und deren Fähigkeiten auswerten. BrowsCap 2.0?
• IE7 + Features: getElementsByClassName, .querySelector, .querySelectorAll, Viewport, XHTML-Handling.
• Viewport-Settings: width, height, user-scalable implementiert, minimum-scale, maximum-scale und initial-scale nicht implementiert.
• CSS-Props: -ms-text-size-adjust, -webkit-text-size-adjust implementiert. Fixed positioning: Hängt am Dok., nicht am Window.

So, das waren dann alle Informationen, die ich auf der MIX gesammelt und für bloggenswert befunden habe.

Allgemein gibt es im Moment ein gewaltiges Aufheulen in der Community, erste Petitionen werden gestartet, das große Jammern setzt ein. Dabei wird gerne übersehen, dass es zwei ganz gewaltige Unterschiede zwischen Windows Phone und Windows Mobile gibt:

1. Windows Phone ist ein kompletter Neustart. Neu, neu, neu – alte Zöpfe wurden abgeschnitten, neue Ansätze ausgelotet. Das System ist darüber hinaus ein klassisches 1er Release, d.h. derzeit fehlende APIs und Funktionalitäten werden ziemlich sicher zukünftig nachgereicht.
2. Die Zielgruppe ist eine komplett andere: Bisher waren es Geschäftskunden in verschiedenen Ausprägungen (klingt irgendwie… krank), jetzt sind es Privatleute. Menschen, die ganz andere Dinge, als beim bisherigen System erwarten. Und damit ändern sich auch die zur Verfügung gestellten Funktionalitäten und die Schwerpunkte der Plattform.

Beide Dinge sollte man verstehen, bevor man anfängt, sich über die Plattform aufzuregen.

• Applikationen sind Page-basiert. #WP7S Struktur: Application -> Frame -> Page(s).
• Navigation zwischen Pages: HyperlinkButtons
• Daten übertragen: QueryString-Parameter im HyperlinkButton
• Zugriff auf die QueryString-Parameter: NavigationContext.QueryString.TryGetValue(<Schlüssel>, out <Variable>);
• In aufgerufener Page: OnNavigatedTo()-Methode überschreiben, um entsprechende Initialisierung vorzunehmen.
• Navigation zurück: NavigationService.GoBack();
• Orientation: SupportedOrientation-Property: Landscape, Portrait, PortraitOrLandscape.
• OnOrientationChanged-Methode für entsprechendes Event überschreibbar.
• App-Bar: Buttons und MenuItems. #WP7S Wichtig: Bilder für Buttons müsen als “Content” kompiliert werden.
• Buttons werden in App-Bar direkt angezeigt, MenuItems sind halt das untergeordnete Menü
• SplashScreen: SplashScreenImage.jpg, muss als “Content” kompiliert werden, wird automatisch angezeigt.
• Standard-Controls beherrschen automatisch Theming und Skinning.
• Push notifications: Vom Server initiiert. Großer Vorteil: Applikation muss nicht wirklich multitasken, wird per Push aktiviert.
• Push Notifications: 3 Typen: Tile-Update, Toast-Notification (kleine Notification-Bar), App-Notification für laufende Applikationen.
• Push-Notification: App sendet URI an eigenen Server, Server pushed an gegebene Applikation, Service benachrichtigt Device.
• Push: Keine spezielle Software nötig, alles HTTP-Requests (POST).
• Channel-URI wird von MS bereitgestellt..
• HttpNotificationChannel-Klasse: HttpNotificationChannel channel = new HttpNotificationChannel(“<APP-Name>”);
• EventHandler für ChannelUriUpdated -> In EventHandler wird die URI entgegen genommen.
• Das Push-Zeug sieht wirklich einfach und angenehm benutzbar aus.
• Location-Services derzeit im Emulator nicht aktiviert.
• Location-APIs sind die gleichen, wie bei Windows 7.
• Location auf drei Wegen: Satellit, WIFI und Triangulation per Basis-Stationen.
• Es gibt einen Location-Service (frei) von Microsoft, so dass man oft auf GPS verzichten könnte.
• Location-Service kann Adresse auflösen.
• Klasse für Geo-Koordinaten: GeoCoordinateWatcher.
• Auflösen von Adressen: CivicAddressResolver-Klasse.
• Location-Handling sieht sehr cool aus.
• BackKey-Abfangen: OnBackKeyPress-Methode überschreiben.
• Obscured / Unobscured-Events für Störungen bzw.. das Weggehen der Störungen. Noch nicht in den MIX-Bits.
• Paused / Unpaused – Applikation wird suspended. Wenn der Benutzer wiederkommt: Resume.
• Wenn Pause, dann alles wegspeichern, App könnte (wird) gekillt werden.
• Resume kann genutzt werden, um den Status wieder herzustellen.

So. Die nächste Session handelt von Performance-Optimierungen / –Überlegungen für Windows Phone 7 Series.

• Kein Zugriff auf die gesamte Kontaktliste, Einzel-Auswahl nur über Chooser
• Keine Bluetooth-API derzeit
• SD-Karten werden für den Programmierer nicht direkt unterstützt – Isolated Storage wird aber entsprechend dynamisch erweitert.
• Kein(!) Cut, Copy & Paste-Support derzeit
• Webbrowser-Control kann konfiguriert werden, so dass es JS ausführt: <Instanz>.EnableScript = true;
• Webbrowser kann zu String navigieren (das, was bei #WM6 nicht funktionierte): <Instanz>.NavigateToString(<HTML>);
• Kommunikation App <-> Webbrowser analog zu Windows: <Browser>.invokeScript(); Von Seite zu App: window.external.<Methode>().
• Eingebautes Webbrowser-Control ist stets die selbe Version, wie der Browser
• Derzeit nur ein MediaElement pro Page.
• Vibrationen auslösen: VibrateController vc = VibrateController.Default; vs.Start(TimeSpan.FromSeconds(60));
• MIC-Input: RAW-WAF-Daten abgreifen. Latenz etwa 10ms
• Accelerometer ansprechen: AccelerometerSensor acc = AccelerometerSensor.Default; Reaktion per ReadingChanged-Event.
• Devicespezifische Assemblies im System.Devices-Namensraum (und entsprechenden Assemblies).
• Accelerometer: X, Y, Z-Richtungen (X ist horizontal, Y ist vertikal, Z ist Entfernung).
• InputScopes in #WP7S geben an, welche Art von Eingabe (Nummern, Email-Adressen, etc.) eingegeben werden kölnnen.
• Basis ist Silverlight 3, zusätzliche Assemblies

Mehr nach der nächsten Session.

Vollständiges Album anzeigen

Inhaltlich ist die Konferenz definitiv spannender als die Bilder.

Das sind die Fakten, die ich gerade einmal aus meiner Twitter-Timeline ziehe:

• VS2010 als primäres Tool für Entwickler
• Der Emulator ist x86-kompiliert, dürfte also um Klassen schneller als der 6.5er-Emulator laufen
• Unterstützung für Push-Notifications, keine Background-Tasks
• LINQ to Objects, LINQ to XML sind verfügbar
• Oberfläche mit Silverlight 3+
• Ganz klar: Kein Migrationspfad von 6.5 nach 7
• Einfachste API, um die Trial-Funktionalität im Marketplace umzusetzen
• Marketplace unterstützt Kreditkarten und Abrechnung durch Netzbetreiber
• Phone als Developer-Phone freischalten funktioniert über Webseite bei MS, Phone wird remote unlocked
• Dateiformat ist XAP
• Ausschließlich .NET-Code, vom System gemanagete Sandbox
• Silverlight für Applikationen, XNA für Spiele, Plattformen sollen zusammenwachsen
• Silverlight soll zukünftig auch auf dei XBox kommen.

Das waren erst einmal die schnellen Fakten. More to come.

So ging es mir heute, als ich über die ObjectForScripting-Eigenschaft des .NET-Webbrowser-Controls gestolpert bin, die es erlaubt, eine Klasse zu definieren, deren Methoden vom Webbrowser-Control bzw. darin enthaltenem JavaScript-Code per window.external.<Methodenname> angesprochen werden kann. Einzige Bedingung: Die Klasse muss COM-sichtbar sein, also das ComVisible-Attribut muss mit dem Wert true gesetzt sein.

Tja, hätte man mal vorher in der Doku nachgeschaut…

Eine gewöhnliche Userdefined Function in C# sieht etwa so aus:

[SqlFunction]
public static SqlString Foo(String input) { ... }

Sowohl Rückgabe, als auch der Übergabeparameter input sind hier auf eine Größe von maximal 8 KByte beschränkt. Wem das nicht ausreicht, der muss das SqlFacet-Attribut verwenden, das sich sowohl oberhalb der Funktion, als auch vor dem Übergabeparameter notieren lässt:

[SqlFunction]
[return: SqlFacet(MaxSize = -1)]
public static SqlString Foo([SqlFacet(MaxSize = -1)] String input) { ... }

Problem gelöst: Die MaxSize-Angabe definiert, dass es keine maximale Größe für den Parameter oder die Rückgabe mehr geben soll. Nach dem erneuten Bereitstellen der Assembly im SQL Server sollte es keine TruncationException mehr geben.

Die JREs kann man dennoch installieren, im Wiki von OneSwarm ist das anschaulich beschrieben und erklärt. Ohne Chance ist man (laut meinem derzeitigen Wissensstand) jedoch, wenn es um die SDKs geht, es sei denn, irgendjemand hätte noch eine gezippte Version davon auf der Platte.

Gegeben sei ein einfaches UserControl TextDisplay.ascx, das eine TextBox anzeigt oder alternativ den eingegebenen Text darstellt:

<%@ Control Language="C#" ClassName="TextDisplayControl" %>
<script runat="server">
   /// <summary>
   /// Zugriff auf den angezeigten Namen
   /// </summary>
   public String Text
   {
      get
      {
         return tbName.Text;
      }
      set
      {
         tbName.Text = value;
      }
   }

   /// <summary>
   /// Behandelt das PreRender-Ereignis
   /// </summary>
   protected override void OnPreRender(EventArgs e)
   {
      // Überprüfen, ob ein PostBack stattgefunden hat
      if(!IsPostBack)
      {
         // Initial das Eingabefeld anzeigen
         ToggleVisibility(true);
      }

      // Daten binden lassen
      DataBind();

      // Weiter verarbeiten lassen
      base.OnPreRender(e);
   }

   /// <summary>
   /// Schaltet die Sichtbarkeit der PlaceHolder um
   /// </summary>
   private void ToggleVisibility(bool showEnterText)
   {
      // Anzeige umschalten
      phEnterText.Visible = showEnterText;
      phShowText.Visible = !showEnterText;
   }

   /// <summary>
   /// Aktiviert die Texteingabe
   /// </summary>
   protected void EditText(object sender, EventArgs e)
   {
      // Eingabefeld anzeigen lassen
      ToggleVisibility(true);
   }

   /// <summary>
   /// Aktiviert die Textausgabe
   /// </summary>
   protected void ShowText(object sender, EventArgs e)
   {
      // Ausgabefeld anzeigen lassen
      ToggleVisibility(false);
   }
</script>
<asp:PlaceHolder runat="server" ID="phEnterText">
   <div>Ihr Name</div>
   <div><asp:TextBox runat="server" ID="tbName" /></div>
   <div><asp:Button runat="server" ID="tbButtonShow"
      Text="Anzeigen" OnClick="ShowText" /></div>
</asp:PlaceHolder>
<asp:PlaceHolder runat="server" ID="phShowText">
   <div>Hallo, <asp:Label runat="server" Text="<%# tbName.Text %>" /></div>
   <div><asp:Button runat="server" ID="tbButtonEdit"
      Text="Bearbeiten" OnClick="EditText" /></div>
</asp:PlaceHolder>

Dieses Steuerelement verfügt über zwei Buttons, deren Ereignisbehandlungsmethoden ShowText und EditText die Umschaltung der beiden Platzhalter, in denen sich die Eingabe- bzw. Ausgabe-Elemente befinden, steuern. Dabei kommt der Standard-ASP.NET-Ereignisverarbeitungsmechanismus zu Einsatz.

In einer Page oder einem übergeordneten Steuerelement wird dieses Control nun dynamisch geladen. Dabei kommt die Methode LoadControl() der Page- bzw. Control-Klasse zum Einsatz. Diese nimmt als Parameter den relativen oder absoluten Pfad zum zu ladenden Steuerelement entgegen. Wichtig dabei ist, das sich das Steuerelement innerhalb des Applikationsverzeichnisses befinden muss – ein Steuerelement aus einem anderen Verzeichnis lässt sich so nicht laden.

Beim Init-Ereignis des ladenden Steuerelements findet der eigentliche Aufruf von LoadControl() statt. Bezogen auf die Ereignisreihenfolge ist Init eines der sehr am Anfang stehenden Ereignisse und möglicherweise nicht ideal bezogen auf das Auslesen von Informationen aus dem Benutzerkontext (Session), denn dieser steht hier noch nicht zur Verfügung. Soll jedoch die Ereignisbehandlung innerhalb des zu ladenden Steuerelements wie gewohnt ablaufen, ist der Eintritt des Init-Ereignisses der beste Zeitpunkt – spätere Events würden dazu führen, das innerhalb des geladenen Steuerelements unter Umständen keine ordnungsgemäße Abarbeitung der Lebenszyklen stattfinden kann (ViewState wird nicht richtig geladen, Events werden nicht korrekt geworfen, etc.).

Nachdem das Steuerelement geladen worden ist, liegt es als Instanz vom Typ Control vor, ist also eher generischen Charakter. Ist jedoch der Klassenname bekannt, kann die geladene Instanz in den konkreten Typ konvertiert werden. Damit sind sämtliche typspezifische Eigenschaften und Methoden erreichbar und können manipuliert werden.

Zuletzt muss das Steuerelement einem anderen, in der Seite befindlichen Steuerelement zur Anzeige zugewiesen werden. Dies geschieht mit Hilfe der Add()-Methode von dessen Controls-Auflistung.

Der Code einer Seite, die das Steuerelement TextDisplay.ascx lädt und einbindet, sieht letztlich so aus:

<%@ Page Language="C#" %>
<script runat="server">

   /// <summary>
   /// Behandelt das Init-Ereignis der Seite
   /// </summary>
   protected override void OnInit(EventArgs e)
   {
      // Laden des Controls
      Control textDisplay = LoadControl("~/TextDisplay.ascx");

      if(!IsPostBack)
      {
         // Control in den konkreten Typ umwandeln
         TextDisplayControl tdc = textDisplay as TextDisplayControl;

         // Initialen Text setzen
         tdc.Text = "Karsten";
      }

      // Control an den PlaceHolder anfügen
      phData.Controls.Add(textDisplay);

      base.OnInit(e);
   }

</script>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
   <head runat="server">
      <title>Eingabeseite</title>
   </head>
   <body>
      <form id="form1" runat="server">
         <h1>Hier können Sie Ihren Namen eingeben</h1>
         <div>
            <asp:PlaceHolder runat="server" ID="phData" />
         </div>
      </form>
   </body>
</html>

Falls Sie sich fragen, woher in Zeile 15 der Klassenname TextDisplayControl stammt: Der wurde in der Control-Deklaration mit Hilfe des Attributs ClassName definiert:

<%@ Control Language="C#" ClassName="TextDisplayControl" %>

Ruft ein Benutzer die Seite im Browser auf, erhält er initial folgende Ausgabe:

Gibt er einen Namen ein und betätigt die Schaltfläche Anzeigen, wird zur zweiten Ansicht gewechselt:

Der Wechsel auf die Eingabeseite zurück geschieht durch Klick auf die Schaltfläche Bearbeiten.

Zusammenfassend bleibt festzuhalten: Steuerelemente lassen sich dynamisch über die Methode LoadControl() nachladen. Sie können anschließend in ihren konkreten Typ konvertiert werden. Wichtig ist, das dieser Prozess so zeitig wie möglich im Lebenszyklus der Seite stattfindet, damit die Ereignisse und Verarbeitungen des dynamisch nachgeladenen Steuerelements korrekt verarbeitet werden können.

Bei den meisten Windows Mobile-Geräten ab Version 6 (wenn nicht bei allen) befindet sich nämlich die MSXML-COM-Komponente auf den Maschinchen. Und diese Komponente kann angesprochen werden – nicht jedoch, ohne vorher die Komponente in das .NET CF-Projekt zu importieren. Leider geht das bei COM-Komponenten nicht direkt – aber es gibt den MIDL-Kompiler, der aus einer .idl-Datei eine .tlb-Datei zaubern kann, die sich wiederum als Referenz dem Projekt hinzufügen lässt.

Folgende Schritte müssen Sie ausführen, um MSXML zu verwenden:

1. Öffnen Sie die Visual Studio-Eingabeaufforderung und wechseln Sie in das Verzeichnis [Programme]\Windows Mobile 6 SDK\PocketPC\Include\Armv4i
2. Lassen Sie die tlb-Datei erstellen, indem Sie

   midl /L . msxml2.idl

   eingeben

3. Kopieren Sie die erzeugte msxml2.tlb-Datei in das Verzeichnis Ihrer .NET CF-Applikation
4. Fügen Sie die Datei Ihrem Projekt als Referenz über das "Durchsuchen"-Tab des Verweis-Dialogs hinzu

Nun können Sie mit Hilfe von MSXML auf die gute, alte, herkömmliche Art und Weise mit XML arbeiten:

// Quelle laden
DOMDocument doc = new DOMDocumentClass();
doc.load("source.xml");

// XSL-Stylesheet laden
DOMDocument xsl = new DOMDocumentClass();
xsl.load("style.xsl");

// Transformation durchführen
string html = doc.transformNode(xsl);

Na bitte, geht doch!

Zum Glück gibt es die XmlMappingSource-Klasse. Die erlaubt es, die Mappings in XML-Dateien abzulegen und somit unabhängig von der Klasse zu halten, was in Bezug auf Wartbarkeit und Entkoppelung von Schichten ohnehin deutlich sinnvoller ist.

Die XmlMappingSource-Klasse verfügt über vier statische Methoden:

• FromReader(): Nimmt eine XmlReader-Instanz entgegen
• FromStream(): Erwartet einen Stream
• FromUrl(): Erwartet die Angabe eines URI
• FromXml(): Akzeptiert eine als XML interpretierbare Zeichenkette

Etwas umständlich ist, das nicht mehrere XML-Dateien zugewiesen werden können, aber da kann man sich ggf. mit kleineren Workarounds (Laden mehrerer Dateien, Überführen in ein Gesamt-XML) behelfen.

Um zu verdeutlichen, wie mit dem XML-basierten Mapping gearbeitet kann, soll im folgendenen Beispiel eine einfache Personen-Klasse verwendet werden:

using System;

namespace XML_LINQ_Sample.Model
{
   /// <summary>
   /// Repräsentiert eine Person
   /// </summary>
   public class Person
   {
      /// <summary>
      /// Initialisierung der Klasse
      /// </summary>
      public Person()
      {
         LastChanged = DateTime.Now;
      }

      /// <summary>
      /// Id der Person, Identity in der Tabelle
      /// </summary>
      public int Id { get; set; }

      /// <summary>
      /// Vorname
      /// </summary>
      public string FirstName { get; set; }

      /// <summary>
      /// Nachname
      /// </summary>
      public string LastName { get; set; }

      /// <summary>
      /// E-Mail-Adresse
      /// </summary>
      public string Email { get; set; }

      /// <summary>
      /// Datum der letzten Änderung
      /// </summary>
      public DateTime LastChanged { get; set; }
   }
}

Das Mapping für diese Klasse kann nun wie folgt aussehen:

<Database Name="Samples"
          xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">

   <!-- Person -->
   <Table Name="Persons" Member="XML_LINQ_Sample.Model.Person">

      <!-- Typ-Definition -->
      <Type Name="XML_LINQ_Sample.Model.Person">

         <!-- ID -->
         <Column Name="Id" Member="Id" IsPrimaryKey="true" IsDbGenerated="true" />

         <!-- Vorname -->
         <Column Name="FirstName" Member="FirstName" />

         <!-- Nachname -->
         <Column Name="LastName" Member="LastName" />

         <!-- Email -->
         <Column Name="EMail" Member="Email" />

         <!-- Letzte Änderung -->
         <Column Name="LastChanged" Member="LastChanged" />
      </Type>

   </Table>

</Database>

Wichtig für dieses Mapping ist die Angabe des korrekten Namensraumes http://schemas.microsoft.com/linqtosql/mapping/2007, da der Inhalt des XML-Dokuments sonst schlicht nicht ausgewertet werden könnte. Die einzelnen Typen werden innerhalb eines Table-Elements in einem Type-Element definiert. Eine Spalte definiert das Column-Element, wobei die beiden Attribute Name und Member Pflichtangaben sind. Zusätzlich werden beim ID-Element die beiden Attribute IsPrimaryKey und IsDbGenerated verwendet. Deren Aufgabe ist es, anzugeben, ob die Spalte den Primärschlüssel der Tabelle repräsentiert (IsPrimaryKey) und ob der jeweilige Wert vom Datenbanksystem automatisch generiert werden soll (IsDbGenerated).

Tipp: Das XML-Dokument sollten Sie als Ressource ihrem Projekt hinzufügen, da dies die Handhabung deutlich erleichtert. In diesem Fall wird es unter dem Namen PersonMapping als Ressource gespeichert.

Innerhalb unseres Programms können Sie nun eine Methode definieren, die diese Ressource lädt und einem DataContext zuweist:

/// <summary>
/// Erzeugt einen DataContext
/// </summary>
private static DataContext GetDataContext()
{
   // ConnectionString-Einstellungen abrufen
   ConnectionStringSettings connStr = ConfigurationManager.ConnectionStrings["Sample"];

   // DbProviderFactory abrufen
   DbProviderFactory factory = DbProviderFactories.GetFactory(connStr.ProviderName);

   // Connection erzeugen lassen
   DbConnection connection = factory.CreateConnection();
   connection.ConnectionString = connStr.ConnectionString;

   // MappingSource definieren
   XmlMappingSource source = XmlMappingSource.FromXml(Resources.PersonMapping);

   // DataContext zurückgeben
   return new DataContext(connection, source);
}

Der "magische Teil" ist die Verwendung einer XmlMappingSource. Ansonsten verhält sich der DataContext, wie Sie es gewohnt sind:

/// <summary>
/// Führt irgendwelche Operationen aus
/// </summary>
public void PerformActions()
{

   // DataContext definieren
   using(DataContext dc = GetDataContext())
   {
      // Schema erzeugen lassen, wenn es
      // noch nicht existiert
      if(!dc.DatabaseExists())
      {
         dc.CreateDatabase();
      }

      // Tabelle referenzieren
      Table<Person> personTable = dc.GetTable<Person>();

      // Datensatz finden
      Person person = (
         from Person p in personTable
         where p.LastName.Equals("Samaschke") &&
               p.FirstName.Equals("Karsten")
         select p).FirstOrDefault();

      // Datensatz gefunden?
      if(null != person)
      {
         // Werte ändern
         person.Email = "name@adresse.de";
         person.LastChanged = DateTime.Now;
      }
      else
      {
         // Datensatz anlegen
         person = new Person();
         person.FirstName = "Karsten";
         person.LastName = "Samaschke";
         person.Email = "name@adresse.de";

         // Datensatz einfügen
         personTable.InsertOnSubmit(person);
      }

      // Änderungen speichern
      dc.SubmitChanges();
   }
}

Mit dem Umweg über die XmlMappingSource schlagen Sie letztlich mehrere Fliegen mit einer Klappe:

• Verwendbarkeit verschiedener Datenbanken oder Datenbanktabellen je nach Szenario
• Verhinderung des Bindens von Klassen an ein bestimmtes O/R-Mapping-Framework
• Bessere Wartbarkeit und Pflegbarkeit Ihres DataLayers

Einziger echter Nachteil ist, das Microsoft diesen Ansatz zwar grundsätzlich dokumentiert, Sie aber bis auf die Klassenbeschreibung der XmlMappingSource und die Definition des XML-Schemas für die Mapping-Dateien keinerlei weitere Unterstützung von Seiten des Anbieters erhalten. Da die Elemente und Attribute jedoch den Standard-LINQ-Code-Attributen entsprechen, können Sie die dort getroffenen Aussagen hier 1:1 übertragen.

Im folgenden Beispiel seien ein Interface IConfiguration und ein Interface IConfigurationFluent definiert, die die gleiche Funktionalität abbilden:

/// <summary>
/// Setzt Konfigurationsinformationen
/// </summary>
public interface IConfiguration
{
   /// <summary>
   /// Breite setzen
   /// </summary>
   void SetWidth(int width);

   /// <summary>
   /// Höhe setzen
   /// </summary>
   void SetHeight(int height);

   /// <summary>
   /// Text setzen
   /// </summary>
   void SetText(string text);

   /// <summary>
   /// Ausführen
   /// </summary>
   void Execute();
}

/// <summary>
/// Setzt Konfigurationsinformationen auf angenehmere Art und Weise
/// </summary>
public interface IConfigurationFluent
{
   /// <summary>
   /// Breite setzen
   /// </summary>
   IConfigurationFluent SetWidth(int width);

   /// <summary>
   /// Höhe setzen
   /// </summary>
   IConfigurationFluent SetHeight(int height);

   /// <summary>
   /// Text setzen
   /// </summary>
   IConfigurationFluent SetText(string text);

   /// <summary>
   /// Ausführen
   /// </summary>
   IConfigurationFluent Execute();
}

Der zusätzliche Definitionsaufwand ist minimal, die Handhabung des Codes nimmt jedoch deutlich zu. Sehen wir uns an, wie man mit dem herkömmlichen Interface arbeitet:

/// <summary>
/// Konfiguriert ein Element auf die "klassische" Art
/// </summary>
public void Configure(IConfiguration config)
{
   // Höhe setzen
   config.SetHeight(20);

   // Breite setzen
   config.SetWidth(40);

   // Text setzen
   config.SetText("Hallo, Welt");

   // Ausführen
   config.Execute();
}

Nichts dagegen einzuwenden. Störend ist nur, das Sie ständig "config" schreiben müssen und Operationen, die zusammen gehören, einzeln durchführen.

Hier ist der funktional gleichwertige Code unter Verwendung des Fluent-Interfaces:

/// <summary>
/// Konfiguriert ein Element auf die "fluente" Art
/// </summary>
public void Configure(IConfigurationFluent config)
{
   // Höhe, Breite, Text setzen und Operation durchführen
   config.SetHeight(20)
         .SetWidth(40)
         .SetText("Hallo, Welt")
         .Execute();
}

Hinweis: Da die implementierten Methoden alle die jeweilige Instanz wieder zurückgeben sollen, muss an deren Ende stets return this; eingefügt werden. Für die Methode SetHeight() könnte eine entsprechende Implementierung also so aussehen:

/// <summary>
/// Setzt die Höhe
/// </summary>
public IConfigurationFluent SetHeight(int height)
{
   // Wert setzen
   this.height = value;

   // Aktuelle Instanz zurück geben
   return this;
}

Wie gesagt: Funktional ist dieser Code gleichwertig, in der alltäglichen Anwendung aber um einiges angenehmer, als der klassische Code. Aus genau diesem Grund wird dieser Ansatz von immer mehr Frameworks eingesetzt – bekanntester Fall ist das NHibernate-Framework, das sehr extensiv davon Gebrauch macht.

Stattdessen greifen Sie auf die Klasse XmlNamespaceManager zurück. Deren Konstruktor nimmt als Parameter die NameTable des Dokuments entgegen. Die Methode AddNamespace() erlaubt es Ihnen im Anschluß, die für Sie relevanten Namensräume zu definieren. Dabei ist zu beachten, das so ein Namensraum stets aus zwei Komponenten besteht: Einem Präfix (der eine Abkürzung für den Namensraum darstellt) und dem URI, dem eigentlichen Namensraum. Das Präfix ist dabei – im Vergleich zum originalen Dokument – frei wählbar, der URI muss dem Namensraum im zu verarbeitenden Dokument entsprechen. Sie erkennen die Namensräume stets anhand der xmlns- und xmlns:xx-Attribute, wobei ersteres einen Standardnamensraum darstellt, der ebenfalls per XmlNamespaceManager-Instanz bekannt gemacht werden muss.

Folgendes Beispiel verwendet die XmlNamespaceManager-Klasse um eine Abfrage auf bestimmte Knoten in einem fiktiven Dokument umzusetzen:

// Dokument erzeugen
XmlDocument doc = new XmlDocument();

// Inhalt einladen
doc.Load("http://...");

// Namespace-Manager für die Verwaltung der Namensräume
XmlNamespaceManager manager = new XmlNamespaceManager(doc.NameTable);

// Namensräume anfügen, wichtig sind die URIs
manager.AddNamespace("xs", "urn:sample"); //xmlns:xs="urn:sample"
manager.AddNamespace("xt", "urn:sample2"); //xmlns:xt="urn:sample2"

// Standard-Namensraum anfügen
manager.AddNamespace(string.Empty, "urn:default"); //xmlns="urn:default"

// Abfrage ausführen
XmlNodeList selected = doc.SelectNodes("//dummy[@xt:text='foo']/xs:name");

Die einzige wirkliche Schwierigkeit bei der Arbeit mit Namensräumen im .NET-Framework besteht letztlich nur darin, diese zu identifizieren. Nachdem Sie diese Leistung erbracht haben, sollten die weiteren Schritte problemlos umsetzbar sein.

Angenommen, sie wollen das Versenden eines Formulars nachstellen, dann würden Sie folgenden Code verwenden können:

// Parameter werden als Name-Wert-Parameter übertragen
string parameters = "name=wert&name2=wert2";

// Request erzeugen
HttpWebRequest request = (HttpWebRequest) WebRequest.Create("http://...");

// Pufferung aktivieren (.NETCF-spezifisch)
request.AllowWriteStreamBuffering = true;

// Zugriffsmethode definieren
request.Method = "POST";

// Inhaltslänge übertragen
request.ContentLength = parameters.Length;

Nachdem Sie so den WebRequest konfiguriert haben, müssen Sie die Daten übertragen. Sie können dies mit Hilfe der Stream-Implementierung erledigen, die Sie über die GetRequestStream()-Methode der WebRequest-Implementierung referenzieren können. Selbst und direkt in den Stream zu schreiben, wäre zwar möglich, aber wozu sich die Finger schmutzig machen, wenn Sie im System.IO-Namensraum bereits eine StreamWriter-Klasse haben, die die ganze Arbeit übernimmt?

// StreamWriter zum Schreiben verwenden
StreamWriter sw = new StreamWriter(request.GetRequestStream());

// Informationen übertragen
sw.Write(parameters);

// Daten senden
sw.Flush();

// StreamWriter schließen
sw.Close();

Wichtig ist in diesem Kontext, das Sie per .Flush() und .Close() das Senden der Daten und das Schließen des StreamWriters explizit vornehmen, da Ihnen ansonsten beim Abrufen der Daten eine ProtocolViolationException um die Ohren fliegt.

Nun können die Daten abgerufen werden. Dies geschieht mit Hilfe einer WebResponse-Implementierung, die sie über die Methode GetResponse() des WebRequests erreichen können. Diese WebResponse-Implementierung verfügt über eine Methode GetResponseStream(), die eine Stream-Implementierung zurück gibt, die es erlaubt, die Rückgabe des Servers abzurufen. Auch hier haben Sie die Wahl: Entweder das Rad neu erfinden, oder einen StreamReader verwenden:

// WebResponse-Implementierung abrufen
HttpWebResponse response = (HttpWebResponse) request.GetResponse();

// StreamReader zum Einlesen des HTMLs
StreamReader sr = new StreamReader(response.GetResponseStream());

// Rückgabe abrufen
string result = sr.ReadToEnd();

// Fertig
sr.Close();

Fertig. So richtig schwer war es eigentlich nicht. Um den Code noch besser nutzbar zu machen, empfiehlt es sich, ihn in einem Try-Catch-Block zu kapseln und die ggf. auftretenden Ausnahmen (keine Verbindung, falsche URL, sonstige Fehler) entsprechend abfangen zu lassen.

Gegeben sei ein Formular mit einem darauf befindlichen Webbrowser-Control namens webBrowser1. Es gibt einen Eventhandler, der an das Navigating-Ereignis gebunden ist und nichts anderes machen soll, als die anzuspringende Adresse auszugeben:

private void webBrowser1_Navigating(object sender, WebBrowserNavigatingEventArgs e)
{
   MessageBox.Show(e.Url.ToString());
}

Beim Load-Ereignis des Formulars wird dem Webbrowser-Control über dessen .DocumentText-Eigenschaft ein einfacher HTML-Code zugewiesen:

private void Form1_Load(object sender, EventArgs e)
{
   string html =
      "<html><head><title>Sample</title></head><body><a href=\"http://www.microsoft.de\">Microsoft.de</a></body></html>";
   webBrowser1.DocumentText = html;
}

Auf einem Gerät mit dem (alten) IE4 gibt es zwei Anzeigen der MessageBox:

Wenn man es mit dem IE6 Mobile (etwa im Windows Mobile 6.5-Emulator) versucht, geschieht dies nicht – es wird nur die initiale MessageBox angezeigt:

Auch ein erneutes Binden des Ereignishandlers funktioniert nicht. Dabei – und das ist interessant – werden JavaScripts beispielsweise innerhalb der Webseite ausgeführt. Aber der Klick auf den Link führt zu keiner Reaktion – noch nicht einmal die referenzierte Webseite wird aufgerufen.

Bisher habe ich keinen Workaround darum gefunden. Ich weiß, dass das OpenCFFramework da was anbietet, aber ich sehe – wenn ich ehrlich bin – nicht wirklich ein, auf ein anderes Framework zu wechseln, wenn es sich doch um eine bereits in der Vergangenheit funktionierende Funktionalität handelt.

Nix da, ich nenne das einen Bug.

Für genau diesen Zweck ist die Eigenschaft Filter der HttpResponse-Klasse geschaffen worden. Diese erlaubt es, eine eigene Stream-Implementierung zu definieren, die eine Ausgabe … naja, filtert. Dabei ist das Schwierigste, diese Implementierung zu entwickeln, jedenfalls dann, wenn man nicht weiß, wie man es anstellen soll.

Die Lösung: Einfach die vorhandene Stream-Implementierung im Konstruktor des eigenen Streams übergeben lassen, in einer Instanzvariablen speichern und dann überall verwenden. Der eigene Filter erbt dabei zwingend von der Basisklasse System.IO.Stream und implementiert die abstrakten Methoden dieser Klasse.

Das sieht dann insgesamt etwa so aus:

using System.IO;
using System.Text;
using System.Text.RegularExpressions;

/// <summary>
/// Eigene Stream-Implementierung zur Manipulation der Ausgabe
/// </summary>
public class CustomResponseFilter : Stream
{
   private Stream stream;

   /// <summary>
   /// Konstruktor der Klasse
   /// </summary>
   public CustomResponseFilter(Stream stream)
	{
	   this.stream = stream;
   }

   #region Standard-Implementierung verwenden
   public override bool CanRead
   {
      get { return stream.CanRead; }
   }

   public override bool CanSeek
   {
      get { return stream.CanSeek; }
   }

   public override bool CanWrite
   {
      get { return stream.CanWrite; }
   }

   public override void Flush()
   {
      stream.Flush();
   }

   public override long Length
   {
      get { return stream.Length; }
   }

   public override long Position
   {
      get
      {
         return stream.Position;
      }
      set
      {
         stream.Position = value;
      }
   }

   public override int Read(byte[] buffer, int offset, int count)
   {
      return stream.Read(buffer, offset, count);
   }

   public override long Seek(long offset, SeekOrigin origin)
   {
      return stream.Seek(offset, origin);
   }

   public override void SetLength(long value)
   {
      stream.SetLength(value);
   }
   #endregion

Nun fehlt noch eine Methode, die für das Schreiben der Ausgabe notwendig und von der abstrakten Stream-Klasse auch erfordert wird: Write(). Und genau die beinhaltet nun den Code, der die Ausgabe manipulieren wird. Dabei wird folgende Vorgehensweise verwendet:

• Der übergebene Inhalt (ein Byte-Array) wird in eine Zeichenkette umgewandelt, um manipuliert werden zu können
• Die Manipulation findet auf der Zeichenkette statt
• Die Zeichenkette wird wieder in ein Byte-Array umgewandelt und per innerem Stream  ausgegeben.

Im Code sieht das dann für ein [URL …]-Tag so aus:

   /// <summary>
   /// Schreibt den Output
   /// </summary>
   public override void Write(byte[] buffer, int offset, int count)
   {
      // Byte-Array in String umwandeln
      string output = Encoding.UTF8.GetString(buffer);

      // Zeichenkette suchen
      string pattern = "\\[URL ([^\\]]+?)\\]";
      string replacement = "<a href=\"$1\" target=\"_blank\">";
      output = Regex.Replace(output, pattern, replacement,
         RegexOptions.IgnoreCase | RegexOptions.Compiled);

      // Schließendes Element suchen
      pattern = "\\[/URL\\]";
      replacement = "</a>";
      output = Regex.Replace(output, pattern, replacement,
         RegexOptions.IgnoreCase | RegexOptions.Compiled);

      // Wieder in Byte-Array umwandeln
      byte[] result = Encoding.UTF8.GetBytes(output);

      // ...ausgeben lassen
      stream.Write(result, offset, count);
   }
}

Somit ist der eigene Filter für die Ausgabe definiert. Wichtig ist, das wir einen Konstruktor haben, der den standardmäßig definierten Outputstream als Parameter entgegen nimmt und diesen für alle Ausgabeoperationen intern verfügbar macht.

Damit dieser Filter dann auch funktioniert, muss er noch aktiviert werden. Dies geschieht durch Zuweisung an die Eigenschaft Filter der Response-Eigenschaft einer Webseite oder gleich in der global.asax beim BeginRequest-Ereignis. Hier ist es auf Ebene einer einzelnen Seite implementiert:

<%@ Page Language="C#" AutoEventWireup="true" %>
<script runat="server">
   protected void Page_Load(object sender, EventArgs e)
   {
      Response.Filter = new CustomResponseFilter(Response.Filter);
   }
</script>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
   <head runat="server">
       <title></title>
   </head>
   <body>
      <form id="form1" runat="server">
         <div>
            <h2>BB-Code als Link</h2>
            [URL http://www.aspextra.de]ASP.extra[/URL]
         </div>
      </form>
   </body>
</html>

Wenn Sie den Filter nicht aktiviert hätten, würden Sie folgende Ausgabe im Browser sehen:

Ist der Filter aktivert, erscheint nicht etwa der BB-Code, sondern ein Link, der die entsprechende Webseite in einem neuen Fenster öffnet:

Den Code zu diesem Artikel können Sie hier herunterladen: OutputStream.zip

Zur Erklärung: Wenn innerhalb einer Methode einer .NET-Klasse eine Exception geworfen wird, dann muss ein Entwickler, der diese Methode aufruft, nichts machen. Er muss noch nicht mal irgendwie reagieren. Oftmals weiß er noch nicht einmal, das es in der Methode eine Exception geben könnte. Der Grund dafür liegt im Verzicht auf einen Mechanismus, der dem Entwickler zuverlässig mitteilt, das in dieser Methode eine bestimmte Exception auftreten kann und diese innerhalb der Methode auch nicht behandelt worden ist. Bei Java gibt es diesen Mechanismus – wenn man dort eine Methode definiert und innerhalb der Methode eine Exception per throw-Schlüsselwort wirft, muß man diese Exception per throws-Schlüsselwort auf Ebene der Methodendeklaration angeben. Das sieht dann etwa so aus:

public void tueWas(String input) throws MySuperDuperException, YourSuperDuperException { … }

Ruft man jetzt diese Methode auf und kümmert sich nicht um MySuperDuperException und YourSuperDuperException, dann weist einen der Java-Compiler dezent mit einem echten Fehler darauf hin. Kompilieren geht schlicht nicht, das geht erst dann, wenn entweder auf der aufrufenden Methode ebenfalls per throws angegeben worden ist, das diese Exceptions nicht behandelt werden oder wenn man eben das Naheliegende macht: try-catch verwenden. So oder so, als Entwickler ist man gezwungen, sich mit diesen Exceptions auseinander zu setzen.

Anders Hejlsberg sieht das anders. Er führt drei Punkte an, die seiner Meinung nach gegen diese Checked Exceptions sprechen: Versionierung, Skalierbarkeit und Unübersichtlichkeit. Gehen wir diese Punkte einmal der Reihenfolge nach durch.

1. Versionierung

Hier sagt Hejlsberg, das Interfaces unveränderlich sein sollten. Wenn man nun in der Weiterentwicklung eines Interfaces eine neue Exception einführt, dann würde das zwangsläufig zu Inkompatibilitäten und zusätzlichem Entwicklungsaufwand führen. Und die meisten Entwickler würden sich ohnehin nicht darum kümmern.

Ich sage, dass das eine komplette Nicht-Aussage ist, denn man führt Exceptions nicht mal einfach so ein (es spricht ganz definitiv nicht für eine durchdachte API, wenn die bei jedem Release geändert wird) und ganz nebenbei kann ich einfach eine neue Exception definieren, die von einer existierenden (und per throws deklarierten Exception) erbt. Dann muss auch nix neu implementiert werden. Das Argument ist schlicht nicht stimmig. Das Einzige, was hier stimmt, ist die Aussage, dass sich Entwickler ohnehin nicht darum kümmern würden – was nun aber letztlich auch eher gegen-, als für sie spricht und Zeichen einer recht unprofessionellen Arbeitseinstellung ist.

2. Skalierbarkeit

Hejlsberg führt aus, das die Checked Exceptions dazu führen würden, das die Entwickler viel zu viele Exceptions zu behandeln hätten und stattdessen eher auf generische try-catch(Exception e)-Statements wechseln würden. Damit hat er grundsätzlich sicher recht – die Programmierer machen das tatsächlich so. Aber aus diesem Grund auf die Checked Exceptions verzichten, nur weil ein paar Zeitgenossen schlicht keine passende Arbeitseinstellung haben? Das ist kein Argument.

Weiterhin merkt er an, das Checked Exceptions tendenziell eher lokaler behandelt werden. In einer großen Applikation sollte es aber ein zentrales Fehlerhandling geben. Soweit folge ich seiner Argumentation noch. Aber: Auch in Java ist es möglich, Exceptions erneut zu werfen und sie – nach der lokalen Behandlung – dem zentralen Fehlermanagement zuzuführen. Insofern greift seine Aussage schlicht nicht. Dazu kommt, das der Ansatz, ohne Checked Exceptions zu arbeiten, eher zu globalen try-catch(Exception e)-Statements oder noch besser try-finally-Statements führt – Fehlerbehandlung und die gezielte Reaktion auf Ausnahmen sieht schlicht anders aus. Das ist – zugespitzt formuliert – schlicht schlechtes und amateurhaftes Programmieren, was am Ende des Tages die Applikation unzuverlässiger und langsamer macht. Nö, das Argument kann man so nicht stehen lassen.

3. Unübersichtlichkeit

Dieses Argument hängt mit dem Skalierbarkeitsargument zusammen: Es wird sehr unübersichtlich, jede mögliche Exceptionform zu behandeln. Aus diesem Grund gibt es bei .NET das try-finally-Konstrukt, was die Auseinandersetzung mit den verschiedenen Exceptions vermeiden helfe und somit der Übersichtlichkeit zugute komme. Sagt jedenfalls Anders Hejlsberg. Ich persönlich halte das für eine komplett falsche Strategie: Ich kann doch nicht schlicht die Fehler ignorieren, statt auf sie zu reagieren! Und selbst wenn meine Reaktion im Ignorieren bestünde, hätte ich mich wenigstens beim Schreiben des Codes damit auseinander gesetzt! Beim try-finally muß ich selbst das nicht (mehr) tun.

Zusammenfassend bleibt festzuhalten, das ich vom Verzicht auf die Checked Exceptions in .NET absolut nicht überzeugt bin. Je mehr Projekte ich mit .NET umsetze, um so mehr stört mich das. Ich meine, natürlich mache ich es so, wie man es sollte:

• Eigene Exception-Typen definieren
• Exceptions werfen und das auch im Kommentar anzeigen
• Exceptions so gezielt und so nah wie möglich abfangen

Alles keine Frage, geschieht auch so. Aber irgendwie ist es – durch die Verwendung von Kommentaren und den Verzicht auf einen dedizierten Kompilerfehler – eben eine reine Kann-Geschichte. Damit sorge ich für Unsicherheiten und für unnötige Fehler, und genau das sollte ja eigentlich vermieden werden.

Inhaltlich wird es hier bei ASP.extra — wie der Untertitel schon verrät — um Tekkie-Themen gehen: .NET, Java, ASP.NET, JSPs, Servlets, JSF, Struts, ASP.NET MVC, …, um nur ein paar Themenbereiche zu nennen, in denen wir uns bewegen werden. Das Mitmachen ist einfach: Jeder Artikel / Beitrag kann kommentiert werden. Wer mag, kann sich registrieren und wird dann von uns ggf. als Autor zugelassen.

Also, auf ein Neues!