b2aat6n

thode mehrere Parameter von einfachen
Typen erwarten, müsste jemand, der den
Code liest, daraus gedanklich die Dienstbeschreibung
erst wieder zusammensetzen.
Das Datenmodell für die Dienstbeschreibung
sieht aus wie in Listing 5.
Die Kontrakte für die Funktionseinheiten
sind in EBC-Manier erstellt. Das bedeutet,
dass sie über sogenannte Inputund
Outputpins verfügen. Inputpins werden
in Form von Methoden modelliert,
Outputpins sind Events. Zu weiteren Details
über EBCs lesen Sie am besten die
Artikelserie von Ralf Westphal, zu finden
unter [1] [2] [3]. Der Kontrakt für das Auswerten
der Argumente sieht aus wie in Listing
6. Auf dem Inputpin In_Process der
Funktionseinheit werden die Kommando-
Listing 4
Eine statische Methode
„Run” verwenden.
EasyService.Run(
args,
"myService",
"Mein Service",
"Ein Service, der nichts tut.",
() => Trace.WriteLine
("OnStart aufgerufen"),
() => Trace.WriteLine
("OnStop aufgerufen")
);
Listing 5
Datenmodell für die Dienstbeschreibung.
public class ServiceBeschreibung
{
public string Name { get; set; }
public string DisplayName { get; set; }
public string Description { get; set; }
}
Listing 6
Argumente auswerten.
public interface IArgumenteAuswerten
{
void In_Process(params string[] args);
event Action Out_Install;
event Action Out_Uninstall;
event Action Out_RunAsService;
}
[Abb. 2] Verfeinerung
des Entwurfs.
zeilenparameter in Form eines string-Arrays
übergeben. Je nachdem, welcher Parameter
übergeben wurde, wird daraufhin
der korrespondierende Outputpin ausgelöst.
Die beiden Kontrakte für die Installation
und Deinstallation sind noch einfacher, da
sie nicht über Outputpins verfügen, siehe
Listing 7.
Und zu guter Letzt ist da noch der Kontrakt
für die Ausführung des Service, siehe
Listing 8.
Damit haben Sie nun alle Kontrakte zusammen
und können mit der Implementierung
beginnen. Wie schon angedeutet,
sind automatisierte Tests an den Stellen
schwierig, an denen die Windows-Infrastruktur
relevant ist. Dies betrifft das Installieren
und Deinstallieren des Dienstes. Ferner
sollte der Kontrakt IServiceAusführen
mit der abstrakten Klasse ServiceBase aus
dem .NET Framework kombiniert werden.
Diese stellt die erforderliche Infrastruktur
für die Dienstausführung zur Verfügung.
Damit die Dienste nicht von ServiceBase
ableiten müssen und tatsächlich keine Abhängigkeiten
zur Windows-Infrastruktur
haben, verwende ich einen Dienstproxy.
Diese Klasse leitet von ServiceBase ab und
bietet zwei Events, die beim Starten bzw.
Stoppen des Dienstes ausgeführt werden.
Dadurch kann ein Lambda-Ausdruck verwendet
werden, und der Dienst ist infra-
Listing 7
Installation und Deinstallation.
public interface IServiceInstallieren
{
void In_Installieren(ServiceBeschreibung beschreibung);
}
public interface IServiceDeinstallieren
{
void In_Deinstallieren(ServiceBeschreibung beschreibung);
}
LÖSUNG
strukturunabhängig. Der Dienstproxy sieht
aus, wie in Listing 9 gezeigt wird.
Diese Klasse ist so simpel, dass ich auf
Tests verzichtet habe. Sie zu ergänzen würde
im Übrigen auch erfordern, die protected
Methoden OnStart und OnStop im
Test aufzurufen. Aufgrund der Vererbung
kann die Sichtbarkeit nicht zu internal geändert
werden. Aufwand und Nutzen stünden
daher in einem sehr ungünstigen Verhältnis.
Da das gesamte Projekt ohnehin
einen Integrationstest erfordert, wird der
ServiceProxy dort mitgetestet.
Sehr gut automatisiert zu testen ist die
Implementierung der Argumentauswertung.
Ich habe die Klasse ArgumenteAuswerten
testgetrieben entwickelt. Listing 10
zeigt zwei der Tests als Beispiele.
Der erste Test prüft, ob beim Aufruf ohne
Parameter der Outputpin Out_RunAs-
Service ausgelöst wird. Dies ist wichtig, da
Windows den Dienst so startet. Der zweite
Test prüft, ob bei Aufruf mit /install der
Event Out_Install ausgelöst wird.
Die zugehörige Implementierung ist einfach
gehalten. Zunächst wird geprüft, ob
kein Argument übergeben wurde. In dem
Fall wird der Event Out_RunAsService ausgeführt.
Andernfalls wird über ein switch-
Statement in die jeweiligen Events verzweigt.
Diese Form der Argumentauswertung
ist zwar zu einfach, um damit etwa zusätzliche
Parameter zu den Optionen parsen
www.dotnetpro.de dotnetpro.dojos.2011 47