Para ver el artículo en inglés, active la casilla Inglés. También puede ver el texto en inglés en una ventana emergente si pasa el puntero del mouse por el texto.
Traducción
Inglés
Esta documentación está archivada y no tiene mantenimiento.

Extender las características de base de datos de Visual Studio

Puede extender Visual Studio Premium o Visual Studio Ultimate creando extensiones de características. Estas extensiones permiten ampliar las características de Visual Studio Premium o Visual Studio Ultimate, como la refactorización, la generación de datos, las pruebas unitarias y el análisis de código de base de datos. Al crear extensiones de características, está usando un marco existente para la característica base, por lo que la cantidad de código que es necesario escribir se reduce considerablemente.

Las extensiones de características tienen puntos de extensibilidad bien definidos. No es preciso tener instalado Visual Studio SDK para crear extensiones de características de Visual Studio Premium o Visual Studio Ultimate.

Tarea de alto nivel

Contenido adicional

Obtenga información sobre los conceptos de extensibilidad de base de datos: antes de extender esas características, debe entender cómo funciona la extensibilidad en Visual Studio Premium o Visual Studio Ultimate. Un proveedor de esquema de base de datos implementa todos los servicios que son específicos de un tipo y una versión determinados de una base de datos (como SQL Server 2008). Esto incluye el analizador que lee y escribe los scripts para esa base de datos; el Modelo de objetos de dominio de script (DOM de script) que representa los scripts; y el modelo de esquema que modela los objetos, relaciones y propiedades de los objetos de base de datos. En Visual Studio Premium o Visual Studio Ultimate, siempre que interactúa con una característica o con una extensión de característica, esas características y extensiones de características funcionan en alguna combinación de los servicios DSP, DOM de script y el modelo de esquema.

Agregar compatibilidad con nuevos tipos de refactorización de base de datos: puede crear extensiones de características para la refactorización de base de datos con el fin de habilitar nuevos tipos de refactorización de base de datos. Cada nuevo tipo de refactorización también necesita uno o más colaboradores de refactorización nuevos.

Agregar compatibilidad con nuevos destinos de refactorización de base de datos: puede permitir que un tipo existente de refactorización de base de datos actualice un nuevo tipo de artefacto, como un archivo de texto, o que se genere a partir de una aplicación de terceros que contiene información de base de datos. Si crea un nuevo tipo de refactorización, debe implementar uno o más colaboradores de refactorización para que ese tipo pueda funcionar en los artefactos contenidos en su proyecto de base de datos.

Definir las nuevas reglas de nuevo análisis de código de base de datos: puede definir nuevas reglas de análisis de código de base de datos que busquen problemas no detectados por las reglas incluidas con Visual Studio Premium o Visual Studio Ultimate.

Crear generadores de datos personalizados: se pueden usar generadores de datos personalizados para generar datos de pruebas realistas que no divulguen información confidencial. Puede crear generadores de datos personalizados para complementar los generadores de datos contenidos en Visual Studio Premium o Visual Studio Ultimate.

Agregar condiciones de prueba unitaria de base de datos personalizadas: definiendo una condición de prueba personalizada, puede comprobar el comportamiento de un objeto de base de datos de distintas formas que las permitidas por las condiciones integradas.

Personalizar el comportamiento del proyecto de base de datos: al definir una característica de proyecto de base de datos personalizada, puede modificar el comportamiento del proyecto de formas que los proyectos de base de datos integrados no admiten.

Para modelar una base de datos, Visual Studio modela tanto los scripts que componen el Lenguaje de definición de datos (DDL) de la base de datos como la base de datos que se generaría si ejecutara esos scripts. DOM de script proporciona el modelo de los scripts de DDL. El modelo de esquema proporciona el modelo de la base de datos resultante.

Flujo de datos entre los componentes de extensibilidad

En el diagrama siguiente muestra cómo fluyen los datos a través de estos componentes.

Flujo de datos entre los componentes de extensibilidad

Flujo de datos entre los componentes de extensibilidad

Las definiciones de los objetos de base de datos se conservan en el proyecto de base de datos en forma de scripts de DDL. Al abrir un proyecto de base de datos, se leen esos scripts y se rellenan dos modelos: el modelo de DOM de script y el modelo de esquema. Las características de Visual Studio Premium interactúan con ambos modelos y, cuando guarda los cambios a los objetos de base de datos, esos cambios se conservan de nuevo en los scripts de DDL.

En el diagrama siguiente se muestran los componentes que interactúan para permitirle extender las características de Database Edition.

Comunicación entre los componentes de extensibilidad

Componentes de extensibilidad en Database Edition

Al abrir o crear cualquier proyecto de base de datos, el componente de administrador de extensiones carga los proveedores de esquema de base de datos registrados. Cuando usa determinadas características para un proveedor de esquema de base de datos (DSP), el componente de administrador de extensiones carga las características y sus extensiones que admiten ese DSP. Por ejemplo, cuando usa las características de refactorización de cambio de nombre para cambiar el nombre de objetos de una base de datos SQL Server 2008, se carga la característica de refactorización, junto con los tipos y colaboradores de refactorización para SQL Server 2008.

El administrador de extensiones

Cuando ejecuta Visual Studio Premium o Visual Studio Ultimate, todos los proyectos de base de datos, proveedores de esquema, características y extensiones de características interactúan con el ExtensionManager singleton. El administrador de extensiones carga una única instancia derivada de DatabaseSchemaProvider para cada proyecto de base de datos. Por ejemplo, cuando Visual Studio Premium o Visual Studio Ultimate abre un proyecto Microsoft SQL Server 2005, el administrador de extensiones carga una instancia de Sql90DatabaseSchemaProvider(que derivó deDatabaseSchemaProvider).

El administrador de extensiones carga las extensiones basándose en el tipo de interfaz implementado por esas extensiones. Por ejemplo, cuando usa la característica de pruebas unitarias de base de datos, el administrador de extensiones devuelve una lista de extensiones registradas que heredan la clase base TestCondition y cuyas extensiones son compatibles con el proveedor de esquema de base de datos para el proyecto de base de datos.

Compatibilidad de extensión de características

Una característica, como la refactorización o el análisis de código estático, consta de componentes que son específicos de un DSP y de componentes que admiten todos los DSP (componentes válidos para todos los DSP). Al definir una extensión de características, se declara la compatibilidad de esa extensión con un DSP concreto o con un DSP base, de manera que la extensión solo se cargue para los tipos de proyecto adecuados. Por ejemplo, podría declarar que su extensión es compatible con Sql90DatabaseSchemaProvider (para restringirlo a proyectos de SQL Server 2005) o con SqlDatabaseSchemaProvider (la clase base para los DSP de SQL Server 2005 y SQL Server 2008). También puede declarar una extensión para que sea compatible con varios DSP concretos. Puede usar este enfoque si no tiene la seguridad de que las versiones futuras hagan que su característica no funcione. Para declarar una característica de manera que sea compatible con todos los DSP, declárela como compatible con la clase base DatabaseSchemaProvider.

Ejemplos

Definir la extensión compatible con un DSP:

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

Definir la extensión compatible con varios DSP:

// 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
{
}

Definir la extensión compatible con todos los DSP:

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

Definir la extensión compatible con ninguno de los DSP:

// 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
{
}

Puede crear extensiones de características que mejoren las capacidades de algunas características de Visual Studio Premium o Visual Studio Ultimate. En la tabla siguiente se describen los tipos de extensiones que puede crear.

Característica

Tipo de extensión

Descripción

Pruebas unitarias de bases de datos

Condiciones de pruebas unitarias

Puede agregar aserciones personalizadas para determinar si las pruebas se realizan correctamente o si hay errores. La mayoría de las API de pruebas unitarias son públicas, pero no representan un punto de extensibilidad. Esas API se usan para crear pruebas unitarias de base de datos escritas en código administrado, como Visual C# o Visual Basic. Para obtener más información, vea Definir condiciones personalizadas para pruebas unitarias de base de datos.

Generación de datos

Generadores de datos

Puede usar la API de extensibilidad para crear generadores de datos personalizados si los generadores de datos se proporcionan con Visual Studio Premium o Visual Studio Ultimate. Para obtener más información, vea Generar datos de pruebas especializados con un generador de datos personalizado.

Análisis de código de base de datos

Reglas de análisis de código

Puede definir sus propias reglas de análisis de código para comprobar si hay problemas concretos en el código de la base de datos. Para obtener más información, vea Crear y registrar reglas adicionales para analizar el código de base de datos.

Refactorización de base de datos

Destinos de refactorización

Se pueden extender los tipos de refactorización existentes para que funcionen en nuevos destinos, como nuevos tipos de archivo. Para obtener más información, vea Tutorial: Extender la refactorización de cambio de nombre de base de datos para que funcione en archivos de texto.

Refactorización de base de datos

Tipos de refactorización

Puede crear nuevos tipos de refactorización, como reemplazar condiciones anidadas con cláusulas de protección. Para obtener más información, vea Crear tipos de refactorización de base de datos personalizados o destinos.

Un proveedor de esquema de base de datos (DSP) consta de tres grupos de componentes:

  • DOM de script: un modelo de objetos y los servicios auxiliares que modelan un script de SQL arbitrario que incluye instrucciones DML y DDL.

  • Modelo de esquema: un modelo de objetos y los servicios auxiliares que modelan los objetos en una instancia de base de datos, como tablas, vistas y procedimientos almacenados.

  • Servicios de interacción con el usuario: una colección de servicios que permiten a los componentes básicos tener acceso a los recursos de la interfaz de usuario, como las cadenas que representan los nombres de objetos, los iconos que representan los tipos de objeto y las categorías, y las jerarquías en las que se muestran esos objetos.

Las funciones principales de un DSP son permitir el procesamiento de scripts DDL en las representaciones DOM de script y modelo de esquema, y permitir la función inversa de reproducir scripts de las dos representaciones modelo.

DOM de script

Un DOM de script proporciona una implementación que analiza un script DDL en un modelo de objetos que representa el script. El DOM de script también proporciona la implementación para reproducir el script original a partir del modelo.

En el diagrama siguiente se muestra cómo fluyen los datos a través del DOM de script.

Flujo de datos a través de DOM de script

Flujo de datos a través de DOM de script

El analizador de DOM de script traduce el script, almacenado en un archivo de texto no estructurado, en un objeto que hereda la interfaz IScriptFragment. El generador de script de DOM de script toma un objeto que hereda la interfaz IScriptFragment y genera el script original. En los proveedores de esquema de base de datos para SQL Server, que están incluidos con Visual Studio Premium o Visual Studio Ultimate, IScriptFragment abstrae un árbol de sintaxis abstracta (AST) y una secuencia de tokens.

Los tokens proporcionan una representación no estructurada de un script. Cada token de la colección tiene:

  • El tipo de token (como palabra clave o literal de cadena)

  • La cadena de token

  • El archivo origen de datos en el que aparece el token

  • El desplazamiento dentro de ese archivo en el que aparece el token

Los árboles de sintaxis abstracta (AST) proporcionan una representación estructurada del script. Cada nodo del AST representa un lote de instrucciones, una instrucción o un componente de una instrucción (como una expresión). Los AST se usan para analizar scripts una vez analizados sintácticamente. También se emplean para generar scripts compilados mediante programación.

El modelo de esquema

La representación del modelo de esquema es un modelo de objetos basado en interfaz que modela una instancia de base de datos activa. Las interfaces están organizadas en una jerarquía de derivación que incluye una única capa abstracta compartida por todos los DSP, junto con cualquier número de capas abstractas destinadas a detalles del modelo más concretos. Por ejemplo, la interfaz ISql90Table hereda ISqlTable, que hereda la interfaz de capa abstracta IDatabaseTable. El modelo de esquema toma los objetos IScriptFragment y los traduce a elementos del modelo de esquema y también realiza la conversión inversa, de elementos del modelo de esquema en objetos IScriptFragment. El modelo de esquema consta de algunas implementaciones de Model Composer. Cada implementación crea un modelo a partir de algún otro recurso del sistema. Por ejemplo, ScriptModelComposer crea un modelo a partir de los archivos de script mantenidos en el proyecto de base de datos.

La infraestructura del modelo de esquema (yModelStore y sus clases auxiliares) implementa las referencias integradas de DOM de script directamente desde los elementos del modelo. Esto permite modelar objetos, como procedimientos almacenados, que contienen scripts arbitrarios.

Un modelo de esquema está formado por una colección de elementos y anotaciones. Los elementos describen el artefacto que se va a modelar (como tablas, vistas, procedimientos almacenados, desencadenadores, columnas, etc.). Las anotaciones se usan para asociar datos arbitrarios al modelo. Los componentes básico del proyecto de base de datos usan las anotaciones, y las características y las extensiones de características del proyecto pueden usarlas también. Tanto los elementos como las anotaciones pueden tener nombre o ser anónimos.

Elementos del modelo

Los elementos constan de propiedades y relaciones. Las propiedades representan datos básicos como enteros, valores booleanos y cadenas, y se emplean para capturar los detalles del modelo. Las relaciones representan conexiones con nombre y con tipos entre los elementos. Por ejemplo, un elemento ISqlTable mantiene una relación de tipo ISqlColumn denominada "Columns" que asocia la tabla a sus columnas.

Existen tres tipos básicos de relaciones:

  • Del mismo nivel: representa una dependencia por un elemento en otro elemento de una manera arbitraria. En SQL Server, la relación entre una vista y una tabla se modelaría mejor como una relación del mismo nivel.

  • Compuesta: representa un elemento que está compuesto de otros elementos. En SQL Server, la relación entre una tabla y sus columnas se modela mejor como una relación compuesta. Un principio clave de una relación compuesta es que los dos elementos se crean a la vez, como una única acción. Los elementos no tienen ningún orden de dependencia, para creación o eliminación. Sin embargo, el modelo mantiene la dirección de dependencia de elemento primario a elemento secundario para permitir dependencias asociativas. Por ejemplo, si una columna tiene una dependencia en un tipo determinado, la dependencia de la tabla primaria en su columna compuesta significa que la tabla también depende del tipo.

  • Jerárquica: representa una jerarquía. Las relaciones jerárquicas difieren de las relaciones compuestas en que la dirección de dependencia es del elemento secundario al elemento primario (en lugar de al contrario). Un ejemplo en SQL Server es la relación entre un esquema y un objeto en propiedad como una tabla o una vista. Una tabla participa en una relación jerárquica con su esquema.

En el diagrama siguiente se muestran los tres tipos diferentes de relaciones que se pueden representar en el modelo de esquema.

Relaciones de objetos en el modelo de esquema

Relaciones de objetos en el modelo de esquema

Cada relación de un modelo declara si es una relación múltiple o una relación única. En todos los casos, un elemento puede mantener una relación vacía. Los modelos pueden ser modelos incompletos del artefacto real.

Los elementos se basados en la interfaz para admitir las siguientes características en una implementación del almacén:

  • Tipo de elemento seguro (identidad)

  • Herencia múltiple

    • Para admitir partes agnósticas del DSP y partes específicas del DSP del sistema

    • Para permitir el uso compartido de "calidades" entre tipos de elementos no relacionados de otra forma

  • Flexibilidad de versiones y extensibilidad

Todas las clases de elementos del modelo implementan la interfaz pública IModelElement. Se puede tener acceso a propiedades, relaciones y anotaciones usando la API de metadatos ModelStore de esta clase. Las interfaces, como IDatabaseTable, sirven para proporcionar acceso (en tiempo de compilación) a las propiedades y relaciones de manera más sencilla y más fácil de mantener.

Anotaciones del modelo

Al igual que los elementos, las anotaciones constan de propiedades. A diferencia de los elementos, las anotaciones no participan en relaciones. En su lugar, las anotaciones se adjuntan a elementos o al propio almacén de modelos. Las anotaciones están fuertemente tipadas y es posible adjuntar una instancia única de una anotación a varios elementos además de al almacén de modelos. Las anotaciones adjuntadas al modelo representan una instancia de anotación que es "global" para el modelo.

Mostrar: