Als Entwickler steht man regelmäßig vor der Aufgabe, Dokumente mit einem bestimmten Format zu lesen und weiterzuverarbeiten. Ebenso kommt es immer wieder vor, dass es für das gewünschte Dokumentenformat noch keinen passenden Parser gibt. Daraus entsteht die Aufgabe, selbst einen kleinen Parser zu entwickeln. Gesagt, getan. Bei Xml- oder Json-Dokumenten etwa ist das i. d. R. auch relativ schnell erledigt. Nicht selten gibt es aber dennoch verschiedene Besonderheiten, die es zu beachten gilt. Etwa bestimmte Elemente in der Datei, die nicht immer enthalten sind. Nehmen wir als Beispiel ein Dokument, welches einen Kassenbon abbildet. Standardmäßig stehen alle Artikel drin, welche der Kunde gekauft hat. Es gibt allerdings weitere Fälle, wie Artikelrückgaben (Pfand), Stornierung einzelner Zeilen durch das Kassenpersonal, rabattierte Artikel etc. Schnell ergibt sich eine längere Liste von Fällen, die das Parsing und die anschließende Weiterverarbeitung beeinflussen. Aus diesem Grund kann es eine gute Idee sein, möglichst viele Teile davon per Testautomatisierung abzusichern.
RK GPXviewer
Überwachen von Coding Conventions per Roslyn Analyzer
Das Projekt RK GPXviewer ist ein Modulith in Form einer Desktop Applikation. Das heißt, dass das Programm in mehrere lose gekoppelte Module aufgeteilt ist. Jedes Modul hat hierbei eine öffentliche Schnittstelle und eine nur innerhalb des Moduls sichtbare Logik. Diese Trennung zwischen öffentlicher Schnittstelle und privaten Logikklassen ist hierbei eine strenge Regel. Sie soll sicherstellen, dass das Geflecht an Modulen auch in Zukunft sauber wartbar und erweiterbar bleibt. Nur wie lässt sich die Einhaltung einer solchen Regel am besten sicherstellen? Alle Module befinden sich in der gleichen Projektmappe, eine Regelverletzung wirkt geradezu einladend. Ist eine notwendige Methode oder Eigenschaft gerade nicht in der Schnittstelle enthalten, ist es relativ einfach, ohne Umwege direkt auf die Logik-Klassen zuzugreifen. Damit das nicht passiert, lassen sich für solche Regeln Roslyn Analyzer schreiben. Diese prüfen den Code während des Compile-Vorgangs und geben nach Wahl direkt Fehler oder Warnungen aus. In diesem Artikel möchte ich auf den Roslyn Analyzer eingehen, welchen ich für RK GPXviewer zur Einhaltung obiger Regel umgesetzt habe.
Prism als Basis von modern strukturierten Applikationen
Auf Prism wurde ich zum ersten Mal bei einem Vortrag bei der .Net Usergroup Regensburg aufmerksam – vor locker 10 Jahren. Zunächst wusste ich gar nicht, um was es sich genau handelt. Nach dem Vortrag und weiterer Recherche hat Prism aber die Art und Weise, wie ich Desktop- und Mobile-Applikationen strukturiert habe, maßgeblich beeinflusst. Ein wichtiger Punkt für mich damals war die Aufteilung einer großen Applikation in mehrere, lose miteinander gekoppelte Module und die dafür bereitgestellten Best Practices. Prism folgt dabei den Grundsätzen des MVVM-Patterns und erweitert dieses um weitere Werkzeuge wie CompositeCommand, dem bereitgestellten EventAggregator oder eben Basisklassen für Module. Zusätzlich wird ein DI-Container integriert. Für die Desktop-Applikation RK GPXviewer [1], welche ich gerade für die Planungen meiner Wander- und Fahrrad-Touren im Sommer baue, verwende ich die aktuelle Version von Prism und möchte hier in diesem Artikel einige Erfahrungen damit teilen.