Información general sobre la extensibilidad de la refactorización de base de datos

Puede extender la funcionalidad de la refactorización de base de datos para proporcionar nuevos tipos de refactorización o refactorizar nuevos tipos de archivo. Puede implementar ambos tipos de extensibilidad de la refactorización de base de datos mediante la creación de extensiones de características. Antes de crear extensiones de características para la refactorización de base de datos, es necesario comprender cómo interactúan los componentes de la refactorización de base de datos y dónde se pueden extender dichos componentes.

Para que la refactorización de base de datos funcione con nuevos destinos, puede crear colaboradores de refactorización personalizados heredando de la clase base abstracta RefactoringContributor. Por ejemplo, puede admitir la refactorización en los archivos de texto o archivos XML incluidos en el proyecto de base de datos.

Para habilitar nuevos tipos de refactorización no incluidos en Visual Studio Premium o Visual Studio Ultimate, puede crear operaciones de refactorización personalizadas heredando de la clase base abstracta RefactoringOperation. Por ejemplo, podría implementar un nuevo tipo de refactorización para reemplazar las secciones condicionales anidadas con cláusulas de protección en una serie de instrucciones IF independientes.

Refactorización de base de datos y colaboradores de refactorización

En el diagrama siguiente, se muestra cómo la refactorización de base de datos hace uso de componentes denominados colaboradores de refactorización para administrar determinados tipos de refactorización.

Información general sobre la extensibilidad de la refactorización de base de datos

Información general sobre la extensibilidad de la refactorización de base de datos

Al aplicar por primera vez una operación de refactorización de base de datos en la sesión actual de Visual Studio, se carga la característica de refactorización junto con todos los tipos y colaboradores de refactorización. El comando especificado se pasa a la característica de refactorización y se inicia el tipo de refactorización especificado. El administrador de colaboradores de refactorización recorre en bucle todos los colaboradores registrados para el tipo de refactorización especificado. Cada tipo de colaborador se aplica a un objeto o conjunto de objetos diferente, y cada tipo puede tener un flujo de datos distinto.

Al implementar un nuevo tipo de refactorización, es preciso crear los colaboradores necesarios para que se admita ese tipo de operación de refactorización. Por ejemplo, quizás desee crear un nuevo tipo de refactorización que reemplace las secciones condicionales anidadas con cláusulas de protección. Dado que ese tipo de refactorización cambiaría únicamente el cuerpo de los procedimientos o funciones y no cambiaría el nombre de ningún objeto de base de datos, solo debería crear un colaborador de objetos de esquema y un colaborador de scripts.

Colaboradores de objetos de esquema

En el diagrama siguiente, se muestra el flujo de datos de un colaborador de refactorización que administra objetos de esquema de base de datos.

Flujo de datos de un colaborador de objetos de esquema

Flujo de datos del colaborador de objetos de esquema

Un colaborador de objetos de esquema actualiza la definición de un objeto de esquema. El colaborador actualiza el almacén de copia durante operación de escritura en el modelo de esquemas de datos. El elemento del modelo actualizado se pasa al Generador del Modelo de objetos de dominio de script (DOM de script) y se utiliza para generar un DOM de script actualizado. El motor de diferencias de DOM de script compara el DOM de script actualizado con el DOM de script de la definición original de ese objeto y se genera un script actualizado.

Colaboradores de referencias

En el diagrama siguiente, se muestra el flujo de datos de un colaborador de referencias que administra las referencias entre los objetos.

Flujo de datos de un colaborador de referencias

Flujo de datos del colaborador de referencias

Un colaborador de referencias recupera todas las referencias y sus desplazamientos desde el modelo de esquemas de datos y actualiza las referencias en el almacén de copia durante operación de escritura del modelo de esquemas de datos. El DOM de script actualizado se compara con el DOM de script original y los resultados se utilizan para actualizar los scripts que contienen las referencias modificadas.

Colaboradores de planes de generación de datos y pruebas unitarias de base de datos

En el diagrama siguiente, se muestra el flujo de datos de los colaboradores de planes de generación de datos y pruebas unitarias de base de datos.

Flujo de datos de los colaboradores de planes de generación de datos y pruebas unitarias de base de datos

Flujo de datos de los colaboradores de DGen y UnitTest

Un colaborador de planes de generación de datos utiliza XPathNavigator para buscar y actualizar los cambios en un plan de generación de datos, que es un archivo XML.

Un colaborador de pruebas unitarias de base de datos analiza el archivo .resx de una prueba unitaria de base de datos y extrae las cadenas de script que están almacenadas en ese archivo. A continuación, se procesan esas cadenas de script utilizando el mismo flujo de datos que el de un colaborador de scripts de base de datos.

Colaboradores de scripts de base de datos

En el diagrama siguiente, se muestra el flujo de datos de un colaborador de scripts de base de datos.

Flujo de datos de un colaborador de scripts de base de datos

Flujo de datos del colaborador de scripts de base de datos

Un colaborador de scripts de base de datos administra las actualizaciones de los scripts anteriores a la implementación, scripts posteriores a la implementación, otros scripts .sql y de las cadenas de script SQL extraídas de las pruebas unitarias de base de datos. El Generador de modelos toma el script y compila un modelo de dicho script en el almacén temporal del modelo de esquemas de datos. El almacén temporal se utiliza para crear un modelo DOM de script modificado. Ese modelo modificado se compara con el modelo del script original y se utilizan las diferencias para generar el script actualizado final.

Colaboradores personalizados

Puede crear colaboradores personalizados para admitir destinos de refactorización adicionales que no se hayan descrito en este tema. Por ejemplo, puede crear un colaborador personalizado para actualizar archivos de texto, documentación de base de datos o salida de herramientas de otros fabricantes. Debe determinar correctamente el flujo de datos necesario para admitir el destino de refactorización. Debe hacer referencia a los tipos descritos anteriormente en este tema si el nuevo tipo de destino se parece a los tipos de destino de un colaborador existente.

Tipos de refactorización de base de datos

Puede habilitar nuevos tipos de refactorización mediante la creación de un nuevo tipo de refactorización. Para crear nuevos tipos de refactorización, implemente al menos cuatro clases que hereden de las siguientes clases base:

  • RefactoringCommand
    Registre esta clase para proporcionar un nuevo tipo de refactorización. La clase especifica los elementos de modelo para los que debe estar disponible el comando y llama a la operación de refactorización cuando el usuario hace clic en el comando.

  • RefactoringOperation
    Esta clase especifica cómo la operación de refactorización interactúa con la ventana de vista previa, especifica las propiedades que describen la operación y crea la clase ContributorInput.

  • ContributorInput
    Esta clase almacena los datos de entrada en la clase RefactoringContributor. Si el colaborador primario necesita colaboradores secundarios para completar la operación de refactorización, es posible que tenga que crear varias clases derivadas de ContributorInput. Por ejemplo, si cambia el nombre de un objeto, no solo debe modificar el propio objeto sino también todas las referencias a ese objeto. Por consiguiente, crearía una clase ContributorInput para el símbolo y otra para todas las referencias al símbolo.

  • RefactoringContributor
    Esta clase compila una lista de propuestas de cambio, basándose en la entrada especificada. Al igual que en el caso de ContributorInput, es posible que tenga que crear varias clases derivadas de RefactoringContributor. Si necesita una clase ContributorInput secundaria, la clase RefactoringContributor primaria creará esa entrada. Debe declarar los proveedores de esquemas de base de datos con los que son compatibles los colaboradores de refactorización. Asimismo, debe registrar todos los colaboradores de un tipo de refactorización y el comando de refactorización.

Destinos de la refactorización de base de datos

Puede extender un tipo de refactorización registrado para que funcione con un nuevo destino, como un nuevo tipo de elemento de modelo o un nuevo archivo. Para que la refactorización funcione con un nuevo destino, deberá crear nuevos colaboradores de refactorización. El nuevo colaborador debe funcionar con una de las clases ContributorInput definidas para ese tipo de refactorización. Para crear un nuevo destino de refactorización o colaborador, implemente al menos una clase que herede de la siguiente clase base:

  • RefactoringContributor
    Esta clase compila una lista de propuestas de cambio, basándose en la entrada especificada. Debe declarar los proveedores de esquemas de base de datos con los que son compatibles los colaboradores de refactorización y debe registrar todos los colaboradores de un tipo de refactorización.