Cenni preliminari sull'estensibilità del refactoring del database

È possibile estendere le funzionalità del refactoring del database per fornire nuovi tipi di refactoring o per effettuare il refactoring di nuovi tipi di file. Entrambi i tipi di estensibilità del refactoring del database possono essere implementati creando estensioni di funzionalità. Prima di creare estensioni di funzionalità per il refactoring del database, è necessario comprendere il modo in cui i componenti del refactoring del database interagiscono e dove sia possibile estendere tali componenti.

Per consentire l'utilizzo del refactoring del database in nuovi database di destinazione, è possibile creare collaboratori di refactoring personalizzati ereditando dalla classe di base astratta RefactoringContributor. Ad esempio, è possibile supportare il refactoring in file di testo o file XML contenuti nel progetto di database.

Per abilitare nuovi tipi di refactoring non inclusi in Visual Studio Premium o Visual Studio Ultimate, è possibile creare operazioni di refactoring personalizzate ereditando dalla classe base astratta RefactoringOperation. Ad esempio, è possibile implementare un nuovo tipo di refactoring per sostituire i condizionali annidati con clausole di protezione in una serie di istruzioni IF separate.

Refactoring del database e collaboratori di refactoring

Nel diagramma seguente è illustrato il modo in cui il refactoring del database utilizza componenti noti come collaboratori di refactoring per gestire determinati tipi di refactoring.

Cenni preliminari sull'estensibilità del refactoring del database

Quando si applica per la prima volta un'operazione di refactoring del database nella sessione corrente di Visual Studio, la funzionalità di refactoring viene caricata con tutti i tipi e i collaboratori di refactoring. Il comando specificato viene passato alla funzionalità di refactoring e il tipo di refactoring specificato viene avviato. Il gestore dei collaboratori di refactoring scorre ogni collaboratore registrato per il tipo di refactoring specificato. Ogni tipo di collaboratore è applicabile a un oggetto o a un set di oggetti diverso; ogni tipo può avere inoltre un flusso di dati diverso.

Quando si implementa un nuovo tipo di refactoring, è necessario creare i collaboratori necessari per supportare quel tipo di operazione di refactoring. Ad esempio, è possibile creare un nuovo tipo di refactoring che sostituisce i condizionali annidati con clausole di protezione. Poiché quel tipo di refactoring modificherebbe soltanto i corpi delle stored procedure o delle funzioni e non i nomi degli oggetti di database, si dovrebbe creare solo un collaboratore degli oggetti dello schema e un collaboratore di script.

Collaboratori degli oggetti dello schema

Nel diagramma seguente è illustrato il flusso di dati di un collaboratore di refactoring che gestisce gli oggetti dello schema del database.

Flusso di dati di un collaboratore degli oggetti dello schema

Un collaboratore degli oggetti dello schema aggiorna la definizione di un oggetto dello schema. Il collaboratore aggiorna l'archivio copy-on-write nel modello dello schema di dati. L'elemento del modello aggiornato viene passato al generatore di modelli a oggetti del dominio di script (modelli DOM di script) e utilizzato per generare un modello DOM di script aggiornato. Quest'ultimo viene confrontato con il modello DOM di script della definizione originale di quell'oggetto dal motore delle differenze dei modelli DOM di script; viene quindi generato uno script aggiornato.

Collaboratori di riferimento

Nel diagramma seguente è illustrato il flusso di dati di un collaboratore di riferimento che gestisce i riferimenti tra oggetti.

Flusso di dati di un collaboratore di riferimento

Un collaboratore di riferimento recupera tutti i riferimenti e i relativi offset dal modello dello schema di dati e aggiorna i riferimenti nell'archivio copy-on-write di tale modello. Il modello DOM di script aggiornato viene confrontato con il modello DOM di script originale e i risultati vengono utilizzati per aggiornare gli script che contengono i riferimenti modificati.

Collaboratori dei piani di generazione dati e degli unit test del database

Nel diagramma seguente è illustrato il flusso di dati dei collaboratori dei piani di generazione dati e degli unit test del database.

Flusso di dati dei collaboratori dei piani di generazione dati e degli unit test del database

Un collaboratore dei piani di generazione dati utilizza XPathNavigator per trovare e aggiornare le modifiche nel piano di generazione dati, che è un file XML.

Un collaboratore degli unit test del database analizza il file con estensione resx per lo unit test del database ed estrae le stringhe dello script archiviate in quel file. Tali stringhe vengono quindi elaborate utilizzando lo stesso flusso di dati di un collaboratore degli script del database.

Collaboratori degli script del database

Nel diagramma seguente è illustrato il flusso di dati di un collaboratore degli script del database.

Flusso di dati di un collaboratore degli script del database

Un collaboratore degli script del database gestisce gli aggiornamenti degli script pre-distribuzione e degli script post-distribuzione, di altri script con estensione sql e delle stringhe dello script SQL estratte dagli unit test del database. Il generatore di modelli prende lo script e ne compila un modello nell'archivio temporaneo del modello dello schema di dati. L'archivio temporaneo viene utilizzato per creare un modello DOM di script modificato. Il modello modificato viene confrontato con il modello dello script originale e le differenze vengono utilizzate per generare lo script aggiornato finale.

Collaboratori personalizzati

È possibile creare collaboratori personalizzati per supportare database di destinazione del refactoring aggiuntivi non descritti in precedenza in questo argomento. Ad esempio, è possibile creare un collaboratore personalizzato per aggiornare i file di testo, la documentazione del database o l'output di strumenti di terze parti. È necessario determinare il flusso di dati corretto necessario per supportare il database di destinazione del refactoring. Se il nuovo tipo di destinazione assomiglia ai tipi di destinazione di un collaboratore esistente, è bene fare riferimento ai tipi descritti precedentemente in questo argomento.

Tipi di refactoring del database

È possibile abilitare nuovi tipi di refactoring creando un nuovo tipo di refactoring. Per creare nuovi tipi di refactoring occorre implementare almeno quattro classi che ereditano dalle seguenti classi di base:

• RefactoringCommand
  Si registra questa classe per fornire un nuovo tipo di refactoring. La classe specifica per quali elementi del modello deve essere disponibile il comando e chiama l'operazione di refactoring quando l'utente fa clic sul comando.

• RefactoringOperation
  Questa classe specifica il modo in cui l'operazione di refactoring interagisce con la finestra di anteprima, specifica le proprietà che descrivono l'operazione e crea ContributorInput.

• ContributorInput
  Questa classe archivia i dati di input in RefactoringContributor. Se il collaboratore primario necessita di collaboratori secondari per completare l'operazione di refactoring, potrebbe essere necessario creare più classi derivate da ContributorInput. Ad esempio, se si sta modificando il nome di un oggetto, non solo si deve modificare l'oggetto stesso ma anche tutti i riferimenti a quell'oggetto. Si creerebbe pertanto un oggetto ContributorInput per il simbolo e un altro per tutti i riferimenti al simbolo.

• RefactoringContributor
  Questa classe compila un elenco di proposte di modifica basato sull'input specificato. Come per ContributorInput, potrebbe essere necessario creare più classi derivate da RefactoringContributor. Se è necessario un oggetto ContributorInput secondario, l'oggetto RefactoringContributor primario crea tale input. È necessario dichiarare i provider dello schema di database con i quali sono compatibili i collaboratori di refactoring. È necessario inoltre registrare tutti i collaboratori di un tipo di refactoring e il comando del refactoring.

Database di destinazione del refactoring del database

È possibile estendere un tipo di refactoring registrato in modo tale che venga utilizzato in un nuovo database di destinazione, ad esempio un nuovo tipo di elemento del modello o un nuovo file. Per consentire l'utilizzo del refactoring in un nuovo database di destinazione, è necessario creare nuovi collaboratori di refactoring. Il nuovo collaboratore deve essere in grado di operare in uno degli oggetti ContributorInput definiti per quel tipo di refactoring. Per creare un nuovo database di destinazione o collaboratore di refactoring occorre implementare almeno una classe che eredita dalla seguente classe di base:

• RefactoringContributor
  Questa classe compila un elenco di proposte di modifica basato sull'input specificato. È necessario dichiarare i provider dello schema di database con i quali sono compatibili i collaboratori di refactoring; è inoltre necessario registrare tutti i collaboratori di un tipo di refactoring.