Clientcodegenerierung

WCF RIA Services

Wenn Sie mit WCF RIA Services ein Silverlight-Projekt und ein Projekt der mittleren Ebene verknüpfen, generiert RIA Services basierend auf Entitäten und Vorgängen, die Sie in der mittleren Ebene verfügbar gemacht haben, Clientproxyklassen für die Clientanwendung. Da RIA Services diese Klassen generiert, müssen Sie keine Anwendungslogik von der mittleren Ebene in die Darstellungsebene duplizieren. Alle Änderungen, die Sie am Code der mittleren Ebene vornehmen, werden mit dem Code der Darstellungsebene synchronisiert, wenn Sie das Clientprojekt neu erstellen. Wenn Sie einer Projektmappe einen RIA Services -Link hinzufügen, wird der Projektmappe eine explizite Buildabhängigkeit hinzugefügt, die das Erstellen des Serverprojekts erzwingt, bevor Code für das Clientprojekt generiert wird.

Der generierte Code befindet sich in einem Ordner mit dem Namen Generated_Code im Clientprojekt. Dieser Ordner ist nur sichtbar, wenn Sie im Fenster Projektmappen-Explorer für das Clientprojekt Alle Dateien anzeigen auswählen. Die Klassen im Ordner Generated_Code sollten nicht direkt geändert werden, da sie überschrieben werden, wenn das Clientprojekt neu erstellt wird. Sie können die generierte jedoch Datei öffnen, um den für das Clientprojekt verfügbaren Code anzuzeigen.

RIA_GeneratedCode

Der Algorithmus zum Generieren des Clientcodes folgt den folgenden grundlegenden Regeln:

  1. Es werden alle Assemblys analysiert, die erstellt wurden oder auf die vom Projekt der mittleren Ebene für Domänendienstklassen, Entitätsklassen oder freigegebenen Code verwiesen wird.

  2. Für jeden mit dem EnableClientAccessAttribute-Attribut markierten Domänendienst wird eine von der DomainContext-Klasse abgeleitete Klasse generiert.

  3. Für jede Abfragemethode, jede benannte Updatemethode (eine Updatemethode, für die die UsingCustomMethod-Eigenschaft auf true festgelegt ist) oder jeden Startvorgang in der Domänendienstklasse wird eine Methode in der Domänenkontextklasse generiert.

  4. Für jede Entitätsklasse, die von einem Domänendienst verfügbar gemacht wird, wird eine Entitätsproxyklasse generiert. Eine Entitätsklasse wird verfügbar gemacht, wenn sie von einer Abfragemethode zurückgegeben wird.

  5. Zur Freigabe markierter Code wird in das Clientprojekt kopiert.

Das folgende Beispiel zeigt den Clientcode, der für ein Projekt der mittleren Ebene generiert wird.

Clientcodegenerierung

DomainService und DomainContext

Für jede Domänendienstklasse wird entsprechend den folgenden Regeln eine von DomainContext abgeleitete Klasse generiert:

  1. Die Domänenkontextklasse wird mit dem gleichen Namespace wie der Domänendienst generiert.

  2. Die Domänenkontextklasse enthält drei Konstruktoren:

    1. Ein Standardkonstruktor, der den für die Kommunikation mit dem Domänendienst über http erforderlichen URI anhand einer WebDomainClient-Klasse einbettet.

    2. Ein Konstruktor, der dem Client das Angeben eines alternativen URI ermöglicht.

    3. Ein Konstruktor, der es dem Client ermöglicht, eine benutzerdefinierte DomainClient-Implementierung bereitzustellen (diese wird in der Regel für Komponententests oder die Umleitung zu einer benutzerdefinierten Transportschicht verwendet).

  3. Für jede Abfragemethode in der Domänendienstklasse wird eine EntityQuery-Methode generiert, die im Clientprojekt verwendet werden kann, um Entitäten zu laden.

  4. Für jeden Startvorgang wird eine entsprechende InvokeOperation-Methode generiert, die verwendet werden kann, um diesen Vorgang asynchron zu starten.

  5. Für jede mit dem Update(UsingCustomMethod=true)-Attribut markierte Methode werden Methoden generiert, mit denen die Methode aufgerufen und bestimmt wird, ob sie aufgerufen wurde.

  6. Öffentliche Methoden im Domänendienst, die Einfügungen, Aktualisierungen oder Löschungen ausführen, führen dazu, dass der generierte EntityContainer im Domänenkontext mit einem EntitySetOperations-Flag erstellt wird, das die auf dem Client zulässigen Vorgänge angibt.

Entitätsklasse und Entitätsproxyklasse

Beim Generieren der Entitätsproxyklasse gelten die folgenden Regeln:

  1. Die Proxyklasse wird mit dem gleichen Namen und Namespace wie die Entitätsklasse in der mittleren Ebene generiert.

  2. Der Stammentitätstyp wird von der Entitätsklasse abgeleitet. Abgeleitete Entitätstypen werden von den entsprechenden Basistypen abgeleitet, die von der mittleren Ebene verfügbar gemacht werden.

  3. Jede öffentliche Eigenschaft in der Entitätsklasse, die einen unterstützten Typ enthält und nicht mit dem ExcludeAttribute-Attribut markiert ist, wird in der Proxyklasse generiert, sofern sie nicht bereits im Clientprojekt vorhanden ist. Weitere Informationen finden Sie im Abschnitt "Vermeiden doppelter Member" weiter unten in diesem Thema. Object ist kein unterstützter Typ.

  4. Jeder Eigenschaftensetter enthält Code, durch den eine Validierung ausgeführt wird und Clients darüber benachrichtigt werden, dass sich die Eigenschaft ändert und sich geändert hat.

  5. Metadatenattribute werden im generierten Code mit der Entitätsklasse kombiniert. Auf dem Client ist keine Metadatenklasse vorhanden.

  6. Wenn möglich, werden benutzerdefinierte Attribute an die Proxyklasse weitergegeben. Eine Beschreibung der Bedingungen, die erfüllt werden müssen, damit das benutzerdefinierte Attribut an das Clientprojekt weitergegeben wird, finden Sie im folgenden Abschnitt "Benutzerdefinierte Attribute".

Es wird nur ein CustomValidationAttribute an den Member weitergegeben, wenn der gleiche Typ und die gleiche Validierungsmethode in mehreren CustomValidationAttribute-Instanzen für diesen Member angegeben sind.

Benutzerdefinierte Attribute

Benutzerdefinierte Attribute werden an die Proxyklasse weitergegeben, wenn das Hinzufügen des benutzerdefinierten Attributs keinen Kompilierungsfehler im Clientprojekt verursacht. Das benutzerdefinierte Attribut wird nur unter den folgenden Bedingungen weitergegeben:

  1. Der benutzerdefinierte Attributtyp muss im Clientprojekt verfügbar sein.

  2. Alle in der Deklaration des benutzerdefinierten Attributs angegebenen Typen müssen im Clientprojekt verfügbar sein.

  3. Der benutzerdefinierte Attributtyp muss öffentliche Setter für alle zugehörigen Eigenschaften oder einen Konstruktor, der das Festlegen von Eigenschaften ohne öffentliche Setter ermöglicht, verfügbar machen.

Wenn ein erforderliches benutzerdefiniertes Attribut nicht an den Client weitergegeben wird, müssen Sie möglicherweise einen Assemblyverweis im Clientprojekt hinzufügen. Fügen Sie einen Verweis auf eine Assembly hinzu, die erforderlich ist, damit das benutzerdefinierte Attribut im Clientprojekt kompiliert wird. Sie können ein benutzerdefiniertes Attribut auch zwischen den Ebenen freigeben, indem Sie es in einer freigegebenen Datei definieren.

Freigegebener Code

Wenn Sie Codedateien zwischen der mittleren Ebene und der Darstellungsebene freigeben, wird der Code ohne Änderungen in das Clientprojekt kopiert. Eine Datei für die Freigabe wird mit einem Namen nach dem Muster *.shared.cs bzw. *.shared.vb angegeben. Die Verzeichnisstruktur aus dem Projekt der mittleren Ebene, die die freigegebenen Dateien enthält, wird unter dem Ordner "Generated_Code" repliziert.

Wenn Sie einen benutzerdefinierten Typ in einer freigegebenen Codedatei hinzufügen und diesen Typ dann von einem Startvorgang zurückgeben, gibt die generierte Methode im Domänenkontext nicht den benutzerdefinierten Typ zurück. Stattdessen gibt die Methode im Domänenkontext einen Typ aus dem Framework zurück. Wenn Sie z. B. einen benutzerdefinierten Typ mit dem Namen MyCustomDictionary erstellen, der IDictionary implementiert, und diesen Typ als Rückgabewert für einen Domänenvorgang angeben, gibt die im Domänenkontext generierte Methode nicht MyCustomDictionary zurück. Stattdessen gibt sie ein Dictionary-Objekt zurück.

Weitere Informationen finden Sie unter Freigegebener Code.

Vermeiden doppelter Member

Beim Generieren einer Entitätsproxyklasse kann es vorkommen, dass der gleiche Typ und der gleiche Member bereits mit partiellen Typen im Clientprojekt definiert wurden. Sie haben den Member möglicherweise in freigegebenem Code definiert oder in Code, der nur im Clientprojekt vorhanden ist. RIA Services überprüft die vorhandenen Member vor dem Generieren der Proxyklasse. Ein Member, der bereits definiert ist, wird nicht in der Proxyklasse generiert.

Siehe auch

Anzeigen: