Freigeben über

Unterschiede zwischen der Verwendung des .NET-Assembly-Konnektors und dem Erstellen eines benutzerdefinierten Konnektors

  • Artikel

Letzte Änderung: Mittwoch, 7. Juli 2010

Gilt für: SharePoint Server 2010

Inhalt dieses Artikels
Verwenden des .NET-Assembly-Konnektors
Erstellen eines benutzerdefinierten Konnektors
Vor- und Nachteile von .NET-Assembly-Konnektor und benutzerdefiniertem Konnektor
Verwendungsmöglichkeiten der verschiedenen Methoden

In diesem Thema wird beschrieben, wann Sie den im Lieferumfang von Microsoft Business Connectivity Services (BCS) enthaltenen .NET-Assembly-Konnektor verwenden sollten und wann Sie einen benutzerdefinierten Konnektor erstellen sollten, um eine Verbindung mit externen Systemen herzustellen, die nicht direkt von Business-Konnektivitätsdienste (Business Connectivity Services) unterstützt werden.

Ein benutzerdefinierter Konnektor wird unabhängig von externen Inhaltstypen erstellt, mit denen eine Verbindung mit einem bestimmten externen System hergestellt wird (z. B. alle Datenbanken oder alle Webdienste), während jede .NET-Verbindungsassembly speziell für einen bestimmten externen Inhaltstyp dient. Außerdem ermöglicht ein benutzerdefinierter Konnektor die Integration der Verwaltungsbenutzeroberfläche, während dies bei einer .NET-Verbindungsassembly nicht der Fall ist.

Verwenden des .NET-Assembly-Konnektors

Führen Sie die folgenden Aktionen aus, wenn Sie den .NET-Assembly-Konnektor verwenden, anstatt einen benutzerdefinierten Konnektor zu erstellen:

  1. Schreiben Sie Code als Microsoft .NET Framework-Klassen, und kompilieren Sie die Klassen in eine primäre DLL und mehrere abhängige DLLs.

  2. Veröffentlichen Sie die DLLs in der Business Data Connectivity-Dienst (BDC)-Datenbank.

  3. Verwenden Sie Microsoft SharePoint Designer, um die .NET-Verbindungsassembly zu ermitteln und ein Modell zu erstellen.

  4. Ordnen Sie jede Entität einer Klasse in der DLL zu, und ordnen Sie jeden BDC-Vorgang in dieser Entität einer Methode in dieser "Klasse" zu.

Wenn ein Benutzer zur Laufzeit einen BDC-Vorgang ausführt, wird die entsprechende Methode in der primären DLL ausgeführt.

Erstellen eines benutzerdefinierten Konnektors

Führen Sie die folgenden Aktionen aus, wenn Sie einen benutzerdefinierten Konnektor erstellen, anstatt den .NET-Assembly-Konnektor zu verwenden:

  1. Implementieren Sie die Schnittstellen ISystemUtility, IConnectionManager und ITypeReflector (nur ISystemUtility ist obligatorisch). Theoretisch können Sie auch den Standardverbindungs-Manager und die EntityInstance-Schnittstellen überschreiben. Darüber hinaus wird durch Implementieren von IAdministrableSystem die Verwaltung von Eigenschaften mithilfe der Verwaltungsbenutzeroberfläche unterstützt, und durch Implementieren von ISystemPropertyValidator werden LobSystem-Eigenschaften beim Importieren überprüft (nicht auf dem Microsoft Office-Client).

  2. Kompilieren Sie den Code in Schritt 1 in eine DLL, und platzieren Sie diese im globalen Assemblycache auf dem Server und den Clients.

  3. Schreiben Sie das Modell-XML für die benutzerdefinierte Datenquelle (das Erstellen von Modellen für benutzerdefinierte Konnektoren wird von SharePoint Designer 2010 nicht unterstützt).

  4. Wenn ein Benutzer zur Laufzeit einen BDC-Vorgang ausführt, wird die Execute-Methode in der ISystemUtility-Klasse aufgerufen. Dadurch wird die Verantwortung für das Ausführen der Back-End-Methode an die Execute-Methode übertragen (gemäß der Implementierung durch den benutzerdefinierten Konnektor).

Vor- und Nachteile von .NET-Assembly-Konnektor und benutzerdefiniertem Konnektor

In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung des .NET-Assembly-Konnektors und eines benutzerdefinierten Konnektors aufgelistet.

.NET-Assembly-Konnektor

Benutzerdefinierter Konnektor

Eine DLL, mit der Geschäftslogik implementiert wird, wird im BDC-Speicher gespeichert. Deshalb müssen Sie die DLL nicht separat im globalen Assemblycache auf dem Client und dem Server platzieren.

Binärdateien, mit denen ein benutzerdefinierter Konnektor implementiert wird, müssen im globalen Assemblycache auf dem Client und dem Server platziert werden.

Die .NET Framework-DLL, mit der Geschäftslogik implementiert wird, wird mithilfe der ClickOnce-basierten Business-Konnektivitätsdienste (Business Connectivity Services)-Bereitstellung auf Clientcomputern mit vollem Funktionsumfang bereitgestellt.

Ein separater Setupvorgang ist erforderlich, um Binärdateien zu installieren, mit denen ein benutzerdefinierter Konnektor implementiert wird.

Auf dem Clientcomputer sind für die Bereitstellung keine Administratorrechte erforderlich.

Auf dem Clientcomputer sind Administratorrechte erforderlich, um die Assembly im globalen Assemblycache zu platzieren.

Externe Listen werden problemlos offline geschaltet, da die erforderlichen Assemblys mithilfe von ClickOnce bereitgestellt werden.

Beim Offlineschalten von externen Listen wird ein Fehler gemeldet, wenn beim Cientsetup die Assembly nicht im globalen Assemblycache platziert wird.

Ein hilfreicher Ansatz, wenn Geschäftslogik über statische APIs verfügbar gemacht werden kann, die selten geändert werden.

Ein hilfreicher Ansatz, wenn Back-End-Schnittstellen häufig geändert werden (sie sind dynamisch).

Das TypeReflector-Standardelement kann damit nicht überschrieben werden (Business-Konnektivitätsdienste (Business Connectivity Services)-Komponente, mit der Typen als .NET Framework-Typen interpretiert werden).

Ermöglicht das Überschreiben des TypeReflector-Standardelements und das Implementieren eines benutzerdefinierten TypeReflector-Elements.

Die 1:1-Zuordnung der BDC-Entität und der .NET Framework-Klasse ist erforderlich. Wenn demnach eine BDC-Entität mehrere Klassen aggregieren muss, muss ein Wrapper geschrieben werden. Hierfür muss die .NET-Verbindungsassembly erneut kompiliert und bereitgestellt werden.

Es gibt keine derartigen Einschränkungen.

DLL-Schnittstellen funktionieren wie ein Back-End für Business-Konnektivitätsdienste (Business Connectivity Services), weshalb das Back-End vollständig vom Business-Konnektivitätsdienste (Business Connectivity Services)-Stapel abstrahiert ist. Da die .NET Framework-Assembly-DLL zusammen mit Business-Konnektivitätsdienste (Business Connectivity Services) geladen wird, gibt es keine Sicherheitsanforderungen. Es wird immer von einem "Passthrough" ausgegangen.

Beim Ansatz mit dem benutzerdefinierten Konnektor können unterschiedliche Arten von Sicherheitsmechanismen von Business-Konnektivitätsdienste (Business Connectivity Services) verwendet werden, einschließlich eines benutzerdefinierten Sicherheitsmechanismus (RevertToSelf, Passthrough sowie Credentials und WindowsCredentials werden von Business-Konnektivitätsdienste (Business Connectivity Services) systemintern unterstützt).

Business-Konnektivitätsdienste (Business Connectivity Services) unterstützt Tools für den .NET-Assembly-Konnektor in SharePoint Designer (Ermittlung) und in Visual Studio 2010 (Entwicklung und Bereitstellung der DLL und des Modells).

Für benutzerdefinierte Konnektoren werden keine Tools unterstützt.

Verwendungsmöglichkeiten der verschiedenen Methoden

Sowohl der .NET-Assembly-Konnektor als auch der benutzerdefinierte Konnektor sind sehr hilfreiche Mechanismen zur Erweiterung von Business-Konnektivitätsdienste (Business Connectivity Services), die von Business-Konnektivitätsdienste (Business Connectivity Services) angeboten werden.

Der Ansatz mit dem .NET-Assembly-Konnektor wird für statische externe Systeme empfohlen. Andernfalls müssen Sie für jede Änderung auf dem Back-End Änderungen an der .NET-Verbindungsassembly-DLL vornehmen. Dies erfordert wiederum die erneute Kompilierung und Bereitstellung der Assembly und der Modelle.

Falls die Back-End-Schnittstellen häufig geändert werden, wird der Ansatz mit dem benutzerdefinierten Konnektor empfohlen. Hiermit sind nur Änderungen am Modell erforderlich.