Erstellen von benutzerdefinierten Funktionen für Datenbankprojekte

Sie können vorhandene Datenbankprojekttypen erweitern, indem Sie eigene Funktionen hinzufügen. So können Sie beispielsweise eine Funktion erstellen, von der eine bestimmte Aktion ausgeführt wird, wenn ein Datenbankprojekt geladen oder gespeichert wird. Darüber hinaus können Sie einen eigenen Datenbankschema-Anbieter sowie ein eigenes unterstützendes Projektsystem erstellen. Diese Erweiterungsmöglichkeit wird hier jedoch nicht behandelt.

Allgemeine Aufgaben

Ziele der Projekterweiterung

Hauptziele der Erweiterungsfunktionen für Datenbankprojekte in Visual Studio 2010:

• Verfügbarmachen der Hauptkomponenten mittels Schnittstellen
  Durch diesen Ansatz wird die Konsistenz zwischen Projektsystem und Schemamodell gewährleistet, da hier anstelle von abstrakten Klassen Schnittstellen zum Einsatz kommen. Von einer einzelnen konkreten Klasse wird die Implementierung mehrerer Schnittstellen erwartet.

• Funktionen werden durch den Erweiterungs-Manager erstellt.
  Funktionen sind für große Teile des Systems (einschließlich Projektmappen-Explorer, Schemaansicht, Projektupgrades und Projekteigenschaften) verantwortlich.

• Funktionen sind erweiterbar.
  Diese Erweiterbarkeit kann mithilfe des Erweiterungs-Managers, mithilfe von XML-Dateien, mithilfe der Registrierung oder mithilfe anderer Ansätze erreicht werden.

• Dienste werden über ihre eigene Schnittstelle verfügbar gemacht.
  DataPackage implementiert IServiceProvider. Jede Kommunikation zwischen Funktionen muss mittels Wartung auf diesen Ebenen behandelt werden. Machen Sie die Funktion nicht als Dienst verfügbar. Erstellen Sie stattdessen eine neue Schnittstelle, eine Wrapperklasse, und machen Sie dann den Wrapper als Dienst verfügbar.

• Das Projektsystem wird durch Ereignisse gesteuert.
  Von DataPackage und ProjectNode() werden Ereignisse bereitgestellt, die die Steuerung des Projektsystems mittels Funktionen ermöglichen. Außerdem können Ereignisse von Funktionen über die jeweilige Dienstschnittstelle bereitgestellt werden. In einigen Fällen empfiehlt sich möglicherweise auch die Verwendung eines Delegaten. Verwenden Sie bei der Entscheidung, von welcher Funktion die Aktion gehandhabt werden soll, ggf. einen ereignisbasierten Ansatz, bei dem eine prioritätsabhängige Interaktion der Funktionen möglich ist.

• Verlassen Sie sich nicht auf die Reihenfolge von Listenern.
  Wenn die Reihenfolge von Listenern für ein Ereignis wichtig ist, erstellen Sie ggf. ein Pre- oder ein Post-Ereignis, oder fügen Sie der von "EventArg" abgeleiteten Klasse ggf. eine Prioritätseigenschaft hinzu.

Komponentenmodellassemblys

Von den folgenden Assemblys wird das Datenbankprojektsystem in Visual Studio bereitgestellt.

• Microsoft.VisualStudio.Data.Schema.Package.dll
  Das Basisprojektsystem. Stellt Funktionsbootstrapping und -ereignisse bereit. Dies schließt datenbankunabhängige Funktionen wie Skripts mit ein.

• Microsoft.VisualStudio.Data.Schema.PackageUI.dll
  Die Satellitenassembly für das datenbankunabhängige Paket.

• Microsoft.VisualStudio.Data.Schema.Package.Sql.dll
  Die SQL Server-spezifischen Funktionen, Editoren und Toolfenster für Visual Studio.

• Microsoft.VisualStudio.Data.Schema.Package.SqlUI.dll
  Die Satellitenassembly für die SQL Server-spezifischen Funktionen, Editoren und Toolfenster.

Erweiterungspunkte

Die folgenden Punkte des Datenbankprojektsystems können erweitert werden:

• IDatabaseProjectFeature (AllowMultipleExtensions =true)
  Der Haupterweiterungspunkt für das Projektsystem. Funktionen werden zum Steuern des Projekts sowie zur Mitwirkung entworfen. Die folgenden Schnittstellen können optional implementiert werden: IOleCommandTarget, IDatabaseProjectPriorityCommandTarget, IDatabaseProjectPropertyPageContributor, IDatabaseProjectExtenderContributor<TExtendee>, IDatabaseProjectAddNewItemParticipant, IDatabaseProjectIdleProcessor und IDatabaseProjectPartialProjectParticipant.

• IDatabaseProjectBuildActionContributor (AllowMultipleExtensions =false)
  Steuert BuildAction-Zeichenfolgen zur Liste mit möglichen Buildvorgängen im Projektsystem bei. Beispiel: Vom SQL Server-Projektsystem werden "Predeploy" und "Postdeploy" beigesteuert.

• IDatabaseProjectUserFileContributor (AllowMultipleExtensions =false)
  Gibt an, welche Eigenschaften an die USER-Datei weitergeleitet werden sollen.

• IDatabaseSchemaViewController (AllowMultipleExtensions =false)
  Füllt die Schemaansicht aus und reagiert auf Ereignisse aus dieser Ansicht.

• IDatabaseProjectFileUpgradeController (AllowMultipleExtensions =false)
  Aktualisiert die Projektdatei als XML-Dokument. Dieser Prozess tritt auf, bevor vom Visual Studio-Projektsystem versucht wird, die Projektinstanz über die Projektzuordnungsinstanz zu laden.

• IDatabaseProjectReferenceController (AllowMultipleExtensions = false)
  Steuert Projektverweise.

• IDatabaseProjectPartialProjectParticipant (AllowMultipleExtensions = true)
  Aktiviert eine Funktion zum Herausfiltern von Dateien, die nicht als partielles Projekt exportiert werden sollen.

• IDatabaseProjectHelpKeywordProvider
  Stellt das Hilfeschlüsselwort des Projektsystems bereit, das verwendet wird, wenn der Kunde F1 drückt.

Datenbankprojektlebenszyklus

Jede Datenbankprojektdatei (DBPROJ-Datei) besitzt eine Eigenschaft mit dem Namen "DSP", durch die ein bestimmter DatabaseSchemaProvider angegeben wird, von dem das Projekt nach dem Öffnen in Visual Studio behandelt wird. Mithilfe dieses Datenbankschemaanbieters wird vom Projektsystem ein Erweiterungs-Manager erstellt. Auf dieser Grundlage werden anschließend alle Projektsystemcontributors und Projektfunktionen konstruiert. Jede Funktion erhält ein Initialize-Ereignis, sodass es sich durch Überwachen von Ereignissen selbst initialisieren und im Projektsystem verankern kann.

Die folgenden Ereignisse werden beim Öffnen/Schließen und Speichern des Projekts ausgelöst:

• NewProjectCreated
  Dieses Ereignis tritt beim erstmaligen Erstellen eines Projekts auf. Sie können dieses Ereignis behandeln, um Assistenten oder Setupdialogfelder anzuzeigen.

• ProjectOpening
  Das Projekt wird geöffnet. Sie können dieses Ereignis behandeln, um dem IDatabaseProjectNode beliebige Dienste hinzuzufügen.

• ProjectOpened
  Dieses Ereignis tritt auf, nachdem alle Dienste hinzugefügt wurden und das Öffnen des Projekts abgeschlossen ist. Das Deserialisieren des vorherigen Projektzustands ist zu diesem Zeitpunkt allerdings noch nicht abgeschlossen. TaskHost und DataSchemaModel sind NULL, bis das ProjectLoaded-Ereignis gesendet wird.

• ProjectLoaded
  Das Projekt wurde vollständig geladen. TaskHost und DataSchemaModel sind einsatzbereit.

• ProjectClosing
  Das Projekt wird geschlossen. Dies ist eine gute Gelegenheit zum Beibehalten aller Zustandsinformationen, die sich außerhalb der Projektdatei befinden.

• ProjectClosed
  Das Projekt wurde geschlossen.

• ProjectSaving
  Vom Projekt wird ein Speichervorgang ausgeführt. Dies ist eine gute Gelegenheit, um sicherzustellen, dass sich die Funktion in einem Zustand befindet, die das Speichern ihrer Persistenz ermöglicht.

• ProjectSaved
  Das Projekt wurde gespeichert.

Fehlerverwaltung

Jedes Projekt verfügt über einen ErrorManager. Einige, aber nicht alle Fehler werden in der DBMDL-Datei beibehalten. Dies wird mithilfe der AddPersistedCategory-Klasse gesteuert. Standardmäßig werden die folgenden Kategorien beibehalten: ModelCategory, ValidationAtBuildCategory und ValidationOnIdleCategory. Wenn Sie eine weitere beibehaltene Kategorie hinzufügen, muss das erneute Laden des Projekts behandelt werden. Zudem müssen die Fehler überprüft und verwaltet werden. Hinweis: Obwohl das Projekt geschlossen wurde, hat der Benutzer unter Umständen die DBPROJ-Datei bearbeitet und eine Datei entfernt, für die Sie einen Fehler melden. Für die Benutzer wäre es sehr verwirrend, wenn im Projekt ein Fehler gemeldet wird, obwohl keine derartige Datei vorhanden ist.

Dem ErrorManager werden Datenbankfehlerobjekte in bestimmten Kategorien hinzugefügt. Die Idee ist, dass die Lebensdauer der Fehler von Projektfunktionen durch die Lebensdauer der Kategorie verwaltet werden kann. Zur Vermeidung von Konflikten zwischen Kategorienamen und anderen Funktionen empfiehlt sich die Verwendung einer GUID als Name. Vom ErrorManager werden mehrere integrierte Kategorien definiert:

• DefaultCategory
  Diese Kategorie wurde für Fehler konzipiert, deren Lebensdauer der Projektlebensdauer entspricht. Deshalb werden dieser Kategorie beispielsweise Fehler hinzugefügt, die beim Laden des Projekts auftreten.

• ModelCategory
  Diese Kategorie muss vom Schema-Manager beispielsweise beim Auftreten von Parserfehlern verwendet werden.

Ähnliche Szenarien

Erstellen benutzerdefinierter Typen oder Regeln für die Datenbankumgestaltung

Erstellen und Registrieren zusätzlicher Regeln für die Datenbankcodeanalyse

Generieren spezialisierter Testdaten mit einem benutzerdefinierten Daten-Generator

Definieren benutzerdefinierter Bedingungen für Datenbankkomponententests

Anpassen von Datenbankbuild und -bereitstellung mithilfe von Build- und Bereitstellungsmitwirkenden

Siehe auch

Konzepte

Erweitern der Datenbankfunktionen von Visual Studio