Schnittstellenentwurfsregeln
Dieser Abschnitt enthält eine kurze Zusammenfassung der Schnittstellenentwurfsregeln und -richtlinien. Einige dieser Regeln sind spezifisch für die COM-Architektur, während andere Einschränkungen sind, die von der Schnittstellenentwurfssprache MIDL auferlegt werden. Ausführliche Informationen zum COM-Schnittstellenentwurf finden Sie unter Anatomie einer IDL-Datei.
Per Definition ist ein Objekt kein COM-Objekt, es sei denn, es implementiert entweder die IUnknown-Schnittstelle oder eine von IUnknown abgeleitete Schnittstelle. Darüber hinaus gelten die folgenden Regeln für alle Schnittstellen, die in einem COM-Objekt implementiert sind:
- Sie müssen über einen eindeutigen Schnittstellenbezeichner (IID) verfügen.
- Sie müssen unveränderlich sein. Sobald sie erstellt und veröffentlicht wurden, kann sich kein Teil ihrer Definition ändern.
- Alle Schnittstellenmethoden müssen einen HRESULT-Wert zurückgeben, damit die Teile des Systems, die die Remoteverarbeitung verarbeiten, RPC-Fehler melden können.
- Alle Zeichenfolgenparameter in Schnittstellenmethoden müssen Unicode sein.
- Ihre Datentypen müssen remotable sein. Wenn Sie einen Datentyp nicht in einen remotable-Typ konvertieren können, müssen Sie Ihre eigenen Marshall- und Entmarshaling-Routinen erstellen. Außerdem hat LPVOID oder void * keine Bedeutung auf einem Remotecomputer. Verwenden Sie ggf. einen Zeiger auf IUnknown.
Hinweis
Die aktuelle Implementierung von MIDL behandelt keine Funktionsüberladung oder mehrfache Vererbung.
Weitere Überlegungen zum Schnittstellenentwurf
Verwenden Sie Zeiger auf Daten sehr sorgfältig. Um die Daten im Adressraum des aufgerufenen Prozesses neu zu erstellen, muss die RPC-Laufzeit die genaue Größe der Daten kennen. Wenn beispielsweise ein CHAR * -Parameter auf einen Zeichenpuffer und nicht auf ein einzelnes Zeichen verweist, können die Daten nicht ordnungsgemäß neu erstellt werden. Verwenden Sie die mit MIDL verfügbare Syntax, um die durch Ihre Typdefinitionen dargestellten Datenstrukturen genau zu beschreiben.
Die Initialisierung ist für Zeiger unerlässlich, die in Arrays und Strukturen eingebettet und über Prozessgrenzen hinweg übergeben werden. Nicht initialisierte Zeiger funktionieren möglicherweise, wenn sie an ein Programm im selben Prozessbereich übergeben werden, aber Proxys und Stubs gehen davon aus, dass alle Zeiger mit gültigen Adressen initialisiert werden oder NULL sind.
Seien Sie beim Aliasieren von Zeigern vorsichtig (damit Zeiger auf denselben Speicherteil zeigen können). Wenn der Aliasing beabsichtigt ist, sollten diese Zeiger in der IDL-Datei als Alias deklariert werden. Zeiger, die als nicht als nicht angegeben deklariert wurden, sollten sich nie aliasen.
Achten Sie darauf, wie Sie Arbeitsspeicher zuweisen und freigeben. Denken Sie daran, dass diese Struktur nach Abschluss des Aufrufs zerstört wird, es sei denn, Sie weisen ein COM-Objekt explizit (mithilfe des Attributs "allocate ") an, eine Datenstruktur frei zu geben, die während eines Out-of-Process-Aufrufs erstellt wurde. Betrachten Sie auch den potenziell destruktiven Mehraufwand, der durch eine ineffiziente Zuordnung von Datenstrukturen entsteht, die jetzt gemarst und entmarshaliert werden müssen.
Schließlich sollten Sie beim Definieren Ihrer HRESULT-Rückgabewerte vorsichtig sein, damit Sie keine Fehlercodes erstellen, die mit COM-definierten FACILITY_ITF-Codes in Konflikt stehen (Werte zwischen 0x0000 und 0x01FF sind reserviert) oder mit anderen HRESULT-Werten mit demselben Wert in Konflikt stehen. Verwenden Sie nach Möglichkeit die universellen COM-Erfolgs- und Fehlerrückgabewerte, und verwenden Sie anstelle eines HRESULT einen out-Parameter, um spezifische Informationen für den Funktionsaufruf zurückzugeben.
Weitere Informationen finden Sie in den folgenden Themen:
Zugehörige Themen