Extension des fonctionnalités de base de données de Visual Studio

Vous pouvez étendre Visual Studio Premium ou Visual Studio Ultimate en créant des extensions de fonctionnalités. Celles-ci permettent d'étendre les fonctionnalités de Visual Studio Premium ou Visual Studio Ultimate que ce soit en matière de refactorisation, de génération de données, de test unitaire ou d'analyse du code de base de données. Lorsque vous créez des extensions de fonctionnalités, vous utilisez une infrastructure existante pour la fonctionnalité de base, donc la quantité de code que vous devez écrire est largement réduite.

Les extensions de fonctionnalités ont des points d'extensibilité précis. Vous ne devez pas nécessairement disposer du Kit de développement logiciel (SDK) Visual Studio pour créer des extensions de fonctionnalités pour Visual Studio Premium ou Visual Studio Ultimate.

Tâches courantes de niveau supérieur

Tâches de niveau supérieur	Contenu de support
En savoir plus sur les concepts dans l'extensibilité de base de données : avant d'étendre ces fonctionnalités, vous devez comprendre le fonctionnement de l'extensibilité dans Visual Studio Premium ou Visual Studio Ultimate. Un fournisseur de schémas de base de données implémente tous les services qui sont spécifiques à une marque et une version particulières d'une base de données (telles que SQL Server 2008). Cela inclut l'analyseur qui lit et écrit les scripts pour cette base de données ; le modèle d'objet de domaine de script (Script DOM) qui représente les scripts ; et le modèle de schéma qui modélise les objets, les relations et les propriétés des objets de base de données. Dans Visual Studio Premium ou Visual Studio Ultimate, toutes les fois que vous interagissez avec une fonctionnalité ou une extension de fonctionnalité, ces fonctionnalités et extensions de fonctionnalités fonctionnent sur certaines combinaisons de services DSP, le Script DOM et le modèle de schéma.	Modélisation d'une base de données Composants d'extensibilité dans Database Edition Types d'extensions de fonctionnalités Composants principaux de fournisseurs de schémas de base de données
Ajouter la prise en charge de nouveaux types de refactorisation de base de données : vous pouvez créer des extensions de fonctionnalités pour la refactorisation de base de données afin d'activer de nouveaux types de refactorisation de base de données. Chaque nouveau type de refactorisation requiert également un ou plusieurs nouveaux collaborateurs de refactorisation.	Vue d'ensemble de l'extensibilité de la refactorisation de base de données Créer des types ou cibles de refactorisation de base de données personnalisés
Ajouter la prise en charge de nouvelles cibles de refactorisation de base de données : vous pouvez activer un type existant de refactorisation de base de données afin de mettre à jour un nouveau type d'artefact, tel qu'un fichier texte, ou une sortie d'une application tierce qui contient les informations sur la base de données. Si vous créez un type de refactorisation, vous devez implémenter un ou plusieurs collaborateurs de refactorisation afin de permettre à ce type de fonctionner sur les artefacts contenus dans votre projet de base de données.	Vue d'ensemble de l'extensibilité de la refactorisation de base de données Créer des types ou cibles de refactorisation de base de données personnalisés
Définir de nouvelles règles d'analyse du code de base de données : vous pouvez définir des nouvelles règles d'analyse du code de base de données qui recherchent des problèmes qui ne sont pas détectés par les règles incluses avec Visual Studio Premium ou Visual Studio Ultimate.	Créer et inscrire des règles supplémentaires pour l'analyse du code d'une base de données
Créer des générateurs de données personnalisés : vous pouvez utiliser des générateurs de données personnalisés pour créer des données de test réalistes qui évitent de divulguer des informations sensibles. Vous pouvez créer des générateurs de données personnalisés pour augmenter les générateurs de données contenus dans Visual Studio Premium ou Visual Studio Ultimate.	Générer des données de test spécialisées à l'aide d'un générateur de données personnalisé
Ajouter des conditions de test unitaire de base de données : en définissant une condition de test personnalisée, vous pouvez vérifier le comportement d'un objet de base de données dans des modes non pris en charge par les conditions de test unitaire intégrées.	Définir des conditions personnalisées pour les tests unitaires de base de données
Personnaliser le comportement de projet de base de données : en définissant une fonctionnalité de projet de base de données personnalisée, vous pouvez modifier le comportement de projet dans des modes non pris en charge par les projets de base de données intégrés.	Créer des fonctionnalités personnalisées pour des projets de base de données

Modélisation d'une base de données

Pour modéliser une base de données, Visual Studio modélise à la fois les scripts qui composent le langage de définition de données (DDL) de la base de données et la base de données qui en résulterait si vous exécutiez ces scripts. Le modèle des scripts DDL est fourni par le Script DOM. Le modèle de la base de données résultante est fourni par le modèle de schéma.

Flux de données entre composants d'extensibilité

Le diagramme suivant affiche la façon dont les données circulent via ces composants.

Flux de données entre composants d'extensibilité

Les définitions des objets de base de données sont rendues persistantes dans le projet de base de données dans le formulaire de scripts DDL. Lorsque vous ouvrez un projet de base de données, ces scripts sont lus et deux modèles sont remplis : les modèles de Script DOM et de schéma. Les fonctionnalités de Visual Studio Premium interagissent avec les deux modèles, et lorsque vous enregistrez des modifications sur les objets de base de données, ces modifications sont répercutées dans les scripts DDL.

Composants d'extensibilité dans Database Edition

Le diagramme suivant affiche les composants qui interagissent pour vous permettre d'étendre les fonctionnalités de Database Edition.

Communication entre les composants d'extensibilité

Lorsque vous ouvrez ou créez tout projet de base de données, le composant de gestionnaire d'extensions charge tous les fournisseurs de schémas de base de données enregistrés. Lorsque vous utilisez des fonctionnalités particulières pour un fournisseur de schémas de base de données (DSP, Database Schema Provider), le composant de gestionnaire d'extensions charge les fonctionnalités et leurs extensions qui prennent en charge ce DSP. Par exemple, lorsque vous utilisez les fonctionnalités de refactorisation de changement de nom pour renommer des objets dans une base de données SQL Server 2008, la fonctionnalité de refactorisation est chargée, avec les types de refactorisation et les collaborateurs pour SQL Server 2008.

Gestionnaire d'extensions

Lorsque vous exécutez Visual Studio Premium ou Visual Studio Ultimate, tous les projets de base de données, fournisseurs de schéma, fonctionnalités et extensions de fonctionnalités interagissent avec l'ExtensionManager singleton. Le gestionnaire d'extensions charge une instance unique dérivée de DatabaseSchemaProviderpour chaque projet de base de données. Par exemple, lorsque Visual Studio Premium ou Visual Studio Ultimate ouvre un projet Microsoft SQL Server 2005, le gestionnaire d'extensions charge une instance de Sql90DatabaseSchemaProvider(dérivé de DatabaseSchemaProvider).

Le gestionnaire d'extensions charge des extensions selon le type d'interface implémenté par ces extensions. Par exemple, lorsque vous utilisez la fonctionnalité de test unitaire de la base de données, le gestionnaire d'extensions retourne une liste d'extensions enregistrées qui héritent de la classe de base TestCondition, et dont les extensions sont compatibles avec le fournisseur de schémas de base de données pour le projet de base de données.

Compatibilité d'extension de fonctionnalité

Une fonctionnalité, telle que la refactorisation ou l'analyse statique du code, contient des composants qui sont spécifiques à un fournisseur de schémas de base de données et des composants qui prennent en charge l'ensemble des fournisseurs de schémas de base de données (composants indépendants du DSP). Lorsque vous définissez une extension de fonctionnalité, vous déclarez la compatibilité de cette extension auprès d'un fournisseur de schémas de base de données spécifique (DSP) ou d'un fournisseur de schémas de base de données standard, de manière à charger l'extension uniquement pour les types de projet appropriés. Par exemple, vous pourriez déclarer que votre extension était compatible avec Sql90DatabaseSchemaProvider (pour le restreindre aux projets SQL Server 2005) ou avec SqlDatabaseSchemaProvider (classe de base pour les fournisseurs de schémas de base de données SQL Server 2005 et SQL Server 2008). Vous pouvez également déclarer une extension afin qu'elle soit compatible avec plusieurs fournisseurs de schémas de base de données spécifiques. Vous pouvez utiliser cette approche si vous n'avez pas la garantie que les versions ultérieures n'arrêtent pas votre fonctionnalité. Pour déclarer qu'une fonctionnalité est compatible avec tous les fournisseurs de schémas de base de données, déclarez-la comme compatible avec la classe de base DatabaseSchemaProvider.

Exemples

Définissez l'extension compatible avec un fournisseur de schémas de base de données :

// SqlSchemaObjectDesigners is defined as compatible with all Sql 
// database services providers.  
[DatabaseSchemaProviderCompatibility (typeof(Sql90DatabaseSchemaProvider))]
internal class SqlSchemaObjectDesigners : ISchemaObjectDesigners
{
}

Définissez l'extension compatible avec plusieurs fournisseurs de schémas de base de données :

// Extension InconclusiveCondition is defined as compatible with all 
// SQL Server database services providers and Oracle database 
// services providers.
[DatabaseSchemaProviderCompatibility (typeof(SqlDatabaseSchemaProvider))]
[DatabaseSchemaProviderCompatibility (typeof(OracleDatabaseSchemaProvider))]
public sealed class InconclusiveCondition : TestCondition
{
}

Définissez l'extension compatible avec tous les fournisseurs de schémas de base de données :

// Extension ReportingService is defined as compatible with all
// database services providers.
[DatabaseSchemaProviderCompatibility (typeof(DatabaseSchemaProvider))]
internal class ReportingService : IReportingService
{
}

Définissez l'extension compatible avec aucun fournisseur de schémas de base de données :

// Extension ExecutionTimeCondition is defined as compatible with no
// database services providers.  That means if a feature
// has an ExtensionManager constructed with null, it will load
// those extensions defined as binding to 
// DspCompatibilityCategory.None
[DatabaseSchemaProviderCompatibility (DspCompatibilityCategory.None)]
public sealed class ExecutionTimeCondition : TestCondition
{
}

Types d'extensions de fonctionnalités

Vous pouvez créer des extensions de fonctionnalités qui améliorent les capacités de plusieurs fonctionnalités de Visual Studio Premium ou Visual Studio Ultimate. Le tableau suivant décrit les types d'extensions que vous pouvez créer.

Fonctionnalité	Type d'extension	Description
Tests unitaires de base de données	Conditions de test unitaire	Vous pouvez ajouter des assertions personnalisées pour déterminer la réussite ou l'échec de vos tests. La plupart des API de test unitaire sont publiques mais ne représentent pas de point d'extensibilité. Ces API sont utilisées pour créer des tests unitaires de base de données qui sont écrits en code managé, tel que Visual C# ou Visual Basic. Pour plus d'informations, consultez Définir des conditions personnalisées pour les tests unitaires de base de données.
Génération de données	Générateurs de données	Vous pouvez utiliser l'API d'extensibilité pour créer des générateurs de données personnalisés si les générateurs de données sont fournis avec Visual Studio Premium ou Visual Studio Ultimate. Pour plus d'informations, consultez Générer des données de test spécialisées à l'aide d'un générateur de données personnalisé.
Analyse du code des bases de données	Règles d'analyse du code	Vous pouvez définir vos propres règles d'analyse du code pour vérifier des problèmes spécifiques dans votre code de base de données. Pour plus d'informations, consultez Créer et inscrire des règles supplémentaires pour l'analyse du code d'une base de données.
Refactorisation de base de données	Refactorisation de cibles	Vous pouvez étendre des types de refactorisation existants pour fonctionner sur de nouvelles cibles, telles que des nouveaux types de fichiers. Pour plus d'informations, consultez Procédure pas à pas : extension de la refactorisation de changement de nom de base de données en vue d'une exécution sur des fichiers texte.
Refactorisation de base de données	Types de refactorisation	Vous pouvez créer des nouveaux types de refactorisation, tels que le remplacement d'éléments conditionnels imbriqués par des clauses de garde. Pour plus d'informations, consultez Créer des types ou cibles de refactorisation de base de données personnalisés.

Composants principaux de fournisseurs de schémas de base de données

Un fournisseur de schémas de base de données (DSP, Database Schema Provider) contient trois groupes de composants :

• Script DOM : un modèle objet et des services de prise en charge qui modélisent un script SQL arbitraire incluant à la fois des instructions DDL et DML.

• Modèle de schéma : un modèle objet et des services de prise en charge qui modélisent les objets dans une instance de base de données, telle que les tables, les vues et les procédures stockées.

• Services d'intervention de l'utilisateur : une collection de services qui permettent aux composants principaux d'accéder à des ressources d'interface utilisateur, telles que les chaînes qui représentent les noms d'objets, les icônes qui représentent les types d'objets et les catégories, et les hiérarchies dans lesquelles afficher ces objets.

Les fonctions principales d'un fournisseur de schémas de base de données sont de permettre le traitement de scripts DDL dans les représentations de Script DOM et de modèle de schéma, et d'activer la fonction inverse de reproduction de scripts à partir des deux représentations de modèles.

Script DOM

Un Script DOM fournit l'implémentation qui analyse un script DDL dans un modèle objet qui représente le script. Le Script DOM fournit également l'implémentation pour reproduire le script d'origine du modèle.

Le diagramme suivant affiche la façon dont les données circulent via le Script DOM.

Flux de données via le Script DOM

L'analyseur de Script DOM traduit le script, stocké dans un fichier texte non structuré, dans un objet qui hérite l'interface IScriptFragment. Le générateur de script dans le Script DOM prend un objet qui hérite de l'interface IScriptFragment et produit le script d'origine. Dans les fournisseurs de schémas de base de données pour SQL Server, inclus avec Visual Studio Premium ou Visual Studio Ultimate, IScriptFragment soustrait une arborescence de syntaxe abstraite (AST, Abstract Syntax Tree) et un flux de données de jeton.

Les jetons fournissent une représentation non structurée d'un script. Chaque jeton dans la collection a :

• le type de jeton (tel qu'un mot clé ou un littéral de chaîne) ;

• la chaîne de jeton ;

• le fichier source dans lequel le jeton s'est produit ;

• l'offset au sein de ce fichier au niveau duquel le jeton s'est produit.

Les arborescences de syntaxe abstraite fournissent une représentation structurée du script. Chaque nœud dans l'AST représente un lot d'instructions, une instruction ou un composant d'une instruction (tel qu'une expression). Les arborescences de syntaxe abstraite sont utilisées pour analyser des scripts après qu'ils ont été analysés. Les arborescences de syntaxe abstraite sont également utilisées pour générer des scripts de compilation par programmation.

Schéma de modèle

La représentation de modèle de schéma est un modèle objet basé sur l'interface qui modélise une instance de base de données active. Les interfaces sont réorganisées dans une hiérarchie de dérivation qui inclut une couche abstraite unique partagée par tous les fournisseurs de schémas de base de données, avec un nombre quelconque de couches abstraites qui ciblent des détails plus spécifiques du modèle. Par exemple, l'interface ISql90Table hérite de ISqlTable, qui hérite de l'interface de couche abstraite IDatabaseTable. Le modèle de schéma prend les objets IScriptFragment et les traduit dans des éléments du modèle de schéma et exécute également la conversion inverse, des éléments du modèle de schéma en objets IScriptFragment. Le modèle de schéma est composé d'un certain nombre d'implémentations de l'éditeur de modèles. Chaque implémentation crée un modèle à partir d'une autre ressource dans le système. Par exemple, le ScriptModelComposer compose un modèle à partir des fichiers de script conservés dans le projet de base de données.

L'infrastructure de modèle de schéma (ModelStore et ses classes de prise en charge) implémente les références Script DOM intégrées directement à partir d'éléments de modèle. Cela permet la modélisation d'objets, telle que les procédures stockées, qui contiennent des scripts arbitraires.

Un modèle de schéma se compose d'une collection d'éléments et d'annotations. Les éléments décrivent l'artefact qui est modélisé (tel que les tables, les vues, les procédures stockées, les déclencheurs, les colonnes, etc). Les annotations sont utilisées pour associer des données arbitraires au modèle. Les annotations sont utilisées par les composants principaux du projet de base de données, et elles peuvent également être utilisées par les fonctionnalités du projet et les extensions de fonctionnalités. Les éléments et les annotations peuvent être nommés ou anonymes.

Éléments de modèle

Les éléments sont composés de propriétés et de relations. Les propriétés représentent des données de base telles que les entiers, les valeurs booléennes et les chaînes, et elles sont utilisées pour capturer les détails du modèle. Les relations représentent des connexions nommées et typées entre des éléments. Par exemple, un élément ISqlTable conserve une relation de type ISqlColumn nommée « Colonnes » qui associe la table à ses colonnes.

Il existe trois types de base de relations :

• Homologue : représente une dépendance d'un élément sur un autre élément d'une façon arbitraire. Dans SQL Server, la relation entre une vue et une table serait le mieux modélisée en tant que relation homologue.

• Composition : représente un élément qui se compose d'autres éléments. Dans SQL Server, la relation entre une table et ses colonnes est le mieux modélisée en tant que relation de composition. Un principe clé d'une relation de composition est que les deux éléments sont créés en même temps, comme une action unique. Les éléments n'ont pas d'ordre de dépendance, pour la création ou la suppression. Toutefois, la direction de dépendance de parent à enfant est conservée par le modèle afin de permettre des dépendances associatives. Par exemple, si une colonne a une dépendance sur un type particulier, la dépendance de la table parente sur sa colonne de composition signifie que la table dépend également du type.

• Hiérarchique : représente une hiérarchie. Les relations hiérarchiques diffèrent des relations de composition car la direction de dépendance est de l'enfant au parent (au lieu de l'inverse). Un exemple dans SQL Server est la relation entre un schéma et un objet possédé tels qu'une table ou une vue. Une table participe à une relation hiérarchique avec son schéma.

Le diagramme suivant affiche les trois différents types de relations qui peuvent être représentées dans le modèle de schéma.

Relations d'objet dans le modèle de schéma

Chaque relation dans un modèle déclare s'il s'agit d'une relation multiple ou unique. Dans tous les cas, un élément peut conserver une relation vide. Les modèles peuvent être des modèles incomplets du véritable artefact.

Les éléments sont basés sur l'interface pour prendre en charge les fonctionnalités suivantes dans une implémentation de magasin :

• Typage fort d'un élément (identité)

• Héritage multiple

  • Pour prendre en charge à la fois les composants indépendants du DSP et les composants spécifiques au DSP du système

  • Pour prendre en charge le partage de « qualités » indépendamment des types d'éléments non liés

• Flexibilité de version et extensibilité

Toutes les classes d'éléments de modèles implémentent l'interface IModelElement publique. L'API des métadonnées ModelStore de cette classe permet d'accéder aux propriétés, aux relations et aux annotations. Les interfaces, telles que IDatabaseTable, servent à fournir l'accès (lié au moment de la compilation) aux propriétés et aux relations d'une façon plus simple et favorisant la maintenance.

Annotations du modèle

À l'instar des éléments, les annotations sont composées de propriétés. Contrairement aux éléments, les annotations ne participent pas aux relations. À la place, les annotations sont attachées aux éléments ou au magasin de modèles lui-même. Les annotations sont fortement typées, et une instance unique d'une annotation peut être attachée à plusieurs éléments en plus du magasin de modèles. Les annotations attachées au modèle représentent une instance d'annotation qui est « globale » sur le modèle.