Quick Links | ||
 Startseite Blog Gästebuch Kontakt Impressum |
||
NQ | ||
 Übersicht Auf CodePlex Einführung Artikel History |
||
Projekte | ||
 NQ awzMB awzIRC |
||
In diesem Artikel sollen ergänzend zum Grundlagenartikel die mit der NQ Core Library 0.2 hinzugekommenen Features vorgestellt werden. Die Ausführungen sind zu Gunsten der Kürze des Artikels relativ oberflächlich gehalten, ausführlichere Informationen sollten der mitgelieferten Dokumentation entnommen werden.
Ursprünglich war die Art, wie NQ-Komponenten und -Services definiert werden, relativ klar abgegrenzt: Es werden alle .NET-Assemblies mit einem bestimmten Namensbestandteil aus dem Bin-Verzeichnis geladen und auf das Vorhandensein gewisser Attribute auf Assembly- und Klassenebene untersucht. Daraus baut der Service-Manager interne Strukturen auf, die zur Laufzeit der Verwaltung der Module dienen.
Version 0.2 führt die sog. Component Loader ein. Dies sind vom Service-Manager getrennte Klassen, die das Laden der Komponenten-Assemblies und das Ermitteln aller Informationen zu den Komponenten und Services übernehmen. Sie liefern dem Service-Manager als Ergebnis lediglich die benötigten internen Strukturen. Der große Vorteil der Component Loader: Sie sind austauschbar. Auf diese Weise können Entwickler die Art der Komponentendefinition an eigene Bedürfnisse anpassen, beispielsweise an die Nutzung einer externen Konfiguration, wie sie bei anderen komponentenorientierten Frameworks üblich ist.
Ein eigener Component Loader implementiert das INQComponentLoader-Interface, das wie folgt definiert ist:
Andreas Weizel
public interface INQComponentLoader
{
IEnumerable<INQComponentInfo> LoadComponentData();
IEnumerable<INQServiceInfo> LoadServiceData();
bool LoadComponentAssemblies(INQComponentInfo componentInfo);
string GetComponentPath();
}
Die Methode LoadComponentData wird durch den Service-Manager aufgerufen, wenn dieser Informationen zu den verfügbaren Komponenten benötigt. Die Methode liefert eine Auflistung (beispielsweise ein Array) von Objekten zurück, welche das INQComponentInfo-Interface implementieren. Der Service-Manager verwendet diese Informationen zum Verwalten der Komponenten.
Nachdem geprüft wurde, ob die vorliegenden Komponenten alle Bedingungen erfüllen, wird für jede Komponente die LoadComponentAssemblies-Methode des Component Loaders aufgerufen. Dies ist für den Fall gedacht, dass die Assemblies nicht ohnehin bereits geladen wurden und die Informationen aus einer externen Konfiguration stammen. Somit können innerhalb dieser Methode selektiv nur die tatsächlich benötigten Assemblies in den Arbeitsspeicher geladen werden.
Nun kann der Service-Manager die Informationen zu den vorhandenen Services abfragen, indem er über die LoadServiceData-Methode eine Auflistung von INQServiceInfo-Objekten erhält. Danach wird der gewohne Ladevorgang fortgeführt.
Standardmäßig wird ein von NQ mitgelieferter Component Loader verwendet: Die Klasse NQAttributeBasedComponentLoader implementiert das bisher dokumentierte und eingangs beschriebene Verhalten, nämlich die Definition der Services über Attribute. Die NQ-Dokumentation bietet Beispiele, wie eine eigene Implementierung eingebunden werden kann.
Ein Problem der bisherigen NQ-Architektur war die starre Abhängigkeit von den mitgelieferten Interfaces. Jede Service-Klasse musste INQService oder ein davon abgeleitetes Interface implementieren. Deshalb führt Release 0.2 der NQ Core Library einen zweiten Weg ein, der ohne diese Interfaces auskommt:
[NQExportedService("MyService")]
public class MyServiceClass
{
public MyServiceClass()
{
// Initialisierung der Service-Instanz
}
~MyServiceClass()
{
// Aufräumcode der Service-Instanz
}
}
Im gezeigten Beispiel treten Klassenkonstruktor und -destruktor an Stelle der INQService-Methoden InitService und DestroyService. Dieser Weg ist im Normalfall deutlich stabiler, da die .NET-Runtime sicher stellt, dass Konstruktor und Destruktor immer ausgeführt werden. Gerade bei DestroyService ist dies dagegen (insbesondere bei Multi-Instance-Services) nicht sichergestellt.
Die Methoden des Service-Managers, die zum Zurückgeben von Service-Instanzen bestimmt waren (z.B. GetService und CreateService), waren mit INQService typisiert. Seit Version 0.2 der NQ Core Library kamen besondere generische Überladungen hinzu, die auch Service-Instanzen zurückgeben können, welche vom Entwickler bestimmte, unabhängige Interfaces implementieren:
ISomeMultiService someService =
NQServiceManager.Instance.CreateService<ISomeMultiService>("SomeMultiInstanceService");
Die Einführung der beschriebenen Technik bedeutet nicht die Ablösung der von NQ bereitgestellten Standard-Interfaces. Stattdessen existiert nun eine zweite Möglichkeit, wie Services definiert werden können, wenn der Code unabhängig vom verwendeten Komponenten-Framework bleiben muss. Im Allgemeinen können auf beiden Wegen definierte Services in einer gemeinsamen Architektur koexistieren, auf Ausnahmen wird in der NQ-Dokumentation hingewiesen.
Im Umgang mit Abhängigkeiten zwischen Service-Instanzen ergeben sich durch die neuen Möglichkeiten Besonderheiten, die in der NQ-Dokumentation ausführlicher beschrieben sind.
Vor Version 0.2 konnte ein Service einen anderen nicht über mehrere Stufen ersetzen. Wurde also Service1 von Service2 ersetzt und Service2 wiederum von Service3, so bedeutete dies nicht, dass ein Zugriff auf Service1 in einer Service3-Instanz resultierte. Vielmehr wurde beim Zugriff auf Service1 eine Instanz von Service2 zurück gegeben, beim direkten Zugriff auf Service2 dagegen eine Instanz von Service3.
Dieses Verhalten wurde seit Release 0.2 geändert. Nun liefert der Service-Manager im oben beschriebenen Fall beim Zugriff auf Service1 tatsächlich eine Service3-Instanz. Die Anzahl der Stufen ist nicht begrenzt.
Version 0.2 führt zwei neue Service-Kategorien ein, um Ladebedingungen für Services und Komponenten besser beschränken zu können: NQHostMode.WebServer und NQHostMode.Browser. Dies deutet auch die angedachten Einsatzmöglichkeiten von NQ in ASP.NET- und (allerdings noch theoretisch) Silverlight-Anwendungen an.