Vue d'ensemble de l'extensibilité de la refactorisation de base de données

Il est possible d'étendre les fonctions de refactorisation de base de données de manière à proposer de nouveaux types de refactorisation ou de refactoriser de nouveaux types de fichier. Vous pouvez implémenter les deux types d'extensibilité pour la refactorisation de base de données en créant des extensions de fonctionnalité. Avant toute chose, il est important de comprendre le mode d'interaction des composants de refactorisation de base de données et de savoir à quels niveaux vous pouvez étendre ces composants.

Pour appliquer la refactorisation de base de données à de nouvelles cibles, la meilleure solution consiste à mettre en place des collaborateurs de refactorisation personnalisés par héritage de la classe de base abstraite RefactoringContributor. Vous pouvez prendre, par exemple, en charge la refactorisation dans des fichiers texte ou des fichiers XML contenus dans le projet de base de données.

Pour activer de nouveaux types de refactorisation non prévus dans Visual Studio Premium ou Visual Studio Ultimate, définissez vos propres opérations de refactorisation en héritant de la classe de base abstraite RefactoringOperation. Pourquoi pas, par exemple, implémenter un nouveau type de refactorisation pour remplacer des éléments conditionnels imbriqués par des clauses de garde dans une série d'instructions IF indépendantes.

Refactorisation de base de données et collaborateurs de refactorisation

Le diagramme suivant montre comment la refactorisation de base de données tire parti des composants (appelés collaborateurs de refactorisation) pour gérer des types spécifiques de refactorisation.

Vue d'ensemble de l'extensibilité de la refactorisation de base de données

La première fois que vous effectuez une opération de refactorisation de base de données dans votre session active de Visual Studio, la fonctionnalité de refactorisation est chargée avec l'ensemble des types de refactorisation et des collaborateurs. La commande spécifiée est alors transmise à la fonctionnalité de refactorisation et le type de refactorisation indiqué est démarré. Le gestionnaire des collaborateurs de refactorisation traite en boucle chaque collaborateur enregistré pour le type de refactorisation spécifié. Chaque type de collaborateur s'applique à un objet ou à un ensemble d'objets différent, et chaque type peut être associé à un flux de données distinct.

Lorsque vous implémentez un type nouveau de refactorisation, vous êtes tenu de créer les collaborateurs prenant en charge ce type d'opération de refactorisation. Admettons, par exemple, que vous souhaitiez prévoir un nouveau type de refactorisation permettant de remplacer des éléments conditionnels imbriqués par des clauses de garde. Comme ce type de refactorisation aurait pour effet de modifier uniquement les corps des procédures ou des fonctions, mais pas les noms de objets de base de données, il suffirait de créer un collaborateur d'objet de schéma et un collaborateur de script.

Collaborateurs d'objets de schéma

Le diagramme suivant présente le flux de données d'un collaborateur de refactorisation chargé de gérer des objets de schéma de base de données.

Flux de données pour un collaborateur d'objet de schéma

Un collaborateur d'objet de schéma met à jour la définition d'un objet de schéma. Le collaborateur met à jour le magasin COW (Copy On Write) dans le modèle de schéma de données. L'élément de modèle mis à jour est transmis au Générateur de modèles d'objet de domaine de script (Script DOM) et sert à générer un Script DOM à jour. Le Script DOM mis à jour est comparé avec le Script DOM de la définition d'origine de cet objet par le moteur Script DOM Diff, et un script mis à jour est généré.

Collaborateurs de références

Le diagramme suivant présente le flux de données d'un collaborateur de références chargé de gérer les références entre les objets.

Flux de données pour un collaborateur de références

Un collaborateur de références extrait toutes les références et leurs offsets à partir du modèle de schéma de données et met à jour les références dans le magasin COW (Copy On Write) du modèle de schéma de données. Le Script DOM mis à jour est comparé avec le Script DOM d'origine, et les résultats sont utilisés pour mettre à jour les scripts contenant les références modifiées.

Plans de génération de données et collaborateurs de tests unitaires de base de données

Le diagramme suivant présente le flux de données pour les plans de génération de données et les collaborateurs de tests unitaires de base de données.

Flux de données pour les collaborateurs des plans de génération de données et des tests unitaires de base de données

Un collaborateur de plans de génération de données a recours à XPathNavigator pour rechercher et mettre à jour les modifications apportées au plan de génération de données (fichier XML).

Un collaborateur de tests unitaires de base de données analyse le fichier .resx correspondant au test unitaire de base de données et extrait les chaînes de script stockées dans ce fichier. Ces chaînes de script sont ensuite traitées à l'aide du même flux de données qu'un collaborateur de script de base de données.

Collaborateurs de script de base de données

Le diagramme suivant présente le flux de données pour un collaborateur de script de base de données.

Flux de données pour un collaborateur de script de base de données

Un collaborateur de script de base de données gère les mises à jour des scripts de prédéploiement, des scripts de post-déploiement, des autres scripts .sql et des chaînes de scripts SQL extraites de tests unitaires de base de données. Le Générateur de modèles produit un modèle à partir du script dans le magasin temporaire du modèle de schéma de données. Le magasin temporaire sert à établir un modèle Script DOM modifié. Ce modèle modifié est comparé avec le modèle du script d'origine, et les différences sont utilisées pour générer le script à jour définitif.

Collaborateurs personnalisés

Vous pouvez créer vos propres collaborateurs pour prendre en charge des cibles de refactorisation supplémentaires non décrites jusqu'à maintenant. Vous pourriez, par exemple, prévoir un collaborateur personnalisé pour mettre à jour des fichiers texte, la documentation d'une base de données ou les sorties produites par les outils de tierces parties. Vous devez déterminer le flux de données permettant de prendre en charge la cible de refactorisation. N'oubliez pas de référencer les types décrits précédemment dans cette rubrique si le nouveau type de cible ressemble aux types de cible d'un collaborateur existant.

Types de refactorisation de base de données

Vous pouvez activer de nouveaux types de refactorisation en créant un type de refactorisation. Pour ce faire, vous devez implémenter au moins quatre classes héritant des classes de base suivantes :

• RefactoringCommand
  Vous enregistrez cette classe pour fournir un type nouveau de refactorisation. La classe spécifie désigne les éléments de modèle auxquels la commande peut s'appliquer et lance votre opération de refactorisation dès que l'utilisateur clique sur la commande.

• RefactoringOperation
  Cette classe précise le mode d'interaction entre votre opération de refactorisation et la fenêtre d'aperçu, spécifie les propriétés décrivant l'opération et crée le ContributorInput.

• ContributorInput
  Cette classe stocke les données d'entrée dans le RefactoringContributor. Si votre collaborateur principal a besoin de collaborateurs secondaires pour effectuer l'opération de refactorisation, vous devrez éventuellement créer plusieurs classes dérivées de ContributorInput. Si vous changez, par exemple, le nom d'un objet, vous devez non seulement modifier l'objet lui-même, mais aussi toutes les références à cet objet. Il faudrait, par conséquent, créer un ContributorInput pour le symbole et un autre pour toutes les références au symbole.

• RefactoringContributor
  Cette classe génère une liste de propositions de modification, selon l'entrée spécifiée. Comme pour le ContributorInput, vous devrez éventuellement créer plusieurs classes dérivées de RefactoringContributor. Si vous avez besoin d'un ContributorInput secondaire, votre RefactoringContributor principal crée cette entrée. Vous devez déclarer les fournisseurs de schémas de base de données avec lesquels vos collaborateurs de refactorisation sont compatibles. Il est indispensable, en outre, d'enregistrer tous les collaborateurs pour un type de refactorisation ainsi que la commande de refactorisation.

Cibles de refactorisation de base de données

Vous pouvez étendre un type enregistré de refactorisation à une nouvelle cible (nouveau type d'élément de modèle ou nouveau fichier, par exemple). Pour ce faire, vous devez créer des collaborateurs de refactorisation. Le nouveau collaborateur doit pouvoir s'appliquer à l'un des ContributorInputs définis pour ce type de refactorisation. Pour créer une cible de refactorisation ou un collaborateur, il convient d'implémenter au moins une classe qui hérite de la classe de base suivante :

• RefactoringContributor
  Cette classe génère une liste de propositions de modification, selon l'entrée spécifiée. Vous devez d'une part, déclarer les fournisseurs de schémas de base de données avec lesquels vos collaborateurs de refactorisation sont compatibles et d'autre part, enregistrer tous les collaborateurs pour un type de refactorisation.