Los controles de origen de datos son un nuevo tipo de control de servidor introducido en Microsoft Visual Studio 2005. Son una parte clave de la arquitectura de enlace de datos y pueden proporcionar un modelo de programación declarativa y un comportamiento de enlace de datos automático a través de controles de enlace de datos. Este artículo y los artículos posteriores de esta serie presentarán los elementos centrales de la implementación de controles de fuentes de datos.
Introducción
En resumen, un control de fuente de datos resume un almacén de datos y algunas operaciones que se pueden realizar con los datos contenidos. El control DataBound está asociado con un control de fuente de datos a través de su propiedad DataSourceID. La mayoría de los almacenes de datos tradicionales son tabulares o jerárquicos, y los controles de las fuentes de datos se dividen en consecuencia. Lo que queremos presentar aquí es el control de fuente de datos en formato tabular.
El control de la fuente de datos en sí no hace mucho; toda la lógica está encapsulada en clases derivadas de DataSourceView. Al menos un DataSourceView debe implementar la función de recuperar (es decir, SELECCIONAR) un conjunto de filas. Puede proporcionar la función de modificar datos (es decir, INSERTAR, ACTUALIZAR y ELIMINAR) (opcional). Los controles vinculados a datos pueden verificar los conjuntos de funciones habilitadas a través de varias propiedades de Can??? El control de fuente de datos en sí es solo un contenedor para una o más vistas con nombres únicos. Por convención, se puede acceder a la vista predeterminada por su nombre o puede estar vacía. Si existe o qué tipo de relación existe entre diferentes vistas se puede definir adecuadamente en función de la implementación de cada control de fuente de datos. Por ejemplo, un control de fuente de datos podría proporcionar diferentes vistas filtradas de los mismos datos a través de diferentes vistas, o podría proporcionar un conjunto de subfilas en una vista secundaria. Puede usar la propiedad DataMember de un control vinculado a datos para seleccionar una vista particular (si el control de origen de datos proporciona varias vistas). Tenga en cuenta que ninguno de los controles de fuente de datos integrados en Whidbey ofrece actualmente múltiples vistas.
Finalmente, permítanme presentarles algunos contenidos. Los controles de fuente de datos (y sus vistas) implementan dos conjuntos de API. El primer conjunto de API es una interfaz abstracta definida para cuatro operaciones de datos comunes que se pueden utilizar de forma regular desde cualquier control vinculado a datos. El segundo grupo es opcional, se define en términos del dominio o almacén de datos que representa, suele estar fuertemente tipado y está destinado a desarrolladores de aplicaciones.
Ejemplo
En estos artículos, implementará un WeatherDataSource que funcionará con la API XML REST (inglés) proporcionada por Weather.com (inglés) para recuperar información meteorológica basada en el código postal. Los controles de fuentes de datos derivados generalmente se implementan primero.
clase pública WeatherDataSource: DataSourceControl {
cadena pública estática de solo lectura
CurrentConditionsViewName = "Condiciones actuales";
WeatherDataSourceView privado _currentConditionsView
privado WeatherDataSourceView {
conseguir {
si (_currentConditionsView == nulo) {
_currentConditionsView = nuevo WeatherDataSourceView (este, CurrentConditionsViewName);
}
devolver _currentConditionsView;
}
}
código postal de cadena pública {
conseguir {
cadena s = (cadena)ViewState["Código postal"];
return (s! = nulo)? s: Cadena.Empty;
}
colocar {
si (String.Compare(valor, código postal,
Comparación de cadenas.Ordinal) != 0) {
ViewState["Código postal"] = valor;
CurrentConditionsView.RaiseChangedEvent();
}
}
}
anulación protegida DataSourceView GetView (cadena nombre de vista) {
if (String.IsNullOrEmpty(nombre de vista) ||
(String.Compare(viewName, CurrentConditionsViewName,
StringComparison.OrdinalIgnoreCase) == 0)) {
devolver CurrentConditionsView;
}
lanzar una nueva ArgumentOutOfRangeException("viewName");
}
anulación protegida ICollection GetViewNames() {
devolver nueva cadena [] {CurrentConditionsViewName};
}
Tiempo público GetWeather() {
devolver CurrentConditionView.GetWeather();
}
}
Como puede ver, la idea básica es implementar GetView para devolver una instancia de vista con nombre y GetViewNames para devolver el conjunto de vistas disponibles.
Aquí elija Derivar de DataSourceControl. Una cosa que no es fácil de notar es que el control vinculado a datos en realidad busca la interfaz IDataSource, y el control DataSource implementa la interfaz implementando GetView y GetViewNames. La razón por la que se necesita la interfaz es para permitir que el control de la fuente de datos sea tabular y jerárquico (si es posible, en cuyo caso derive del modelo principal e implemente otro modelo como interfaz). En segundo lugar, también permite convertir otros controles en varios escenarios para duplicar la capacidad de la fuente de datos. Tenga en cuenta también la propiedad pública ZipCode y el método GetWeather que devuelve un objeto Weather fuertemente tipado. Esta API es adecuada para desarrolladores de páginas. Los desarrolladores de páginas no necesitan pensar en DataSourceControl y DataSourceView.
El siguiente paso es implementar la vista de la fuente de datos. Este ejemplo en particular solo proporciona funcionalidad de nivel SELECT (que es el requisito mínimo y la única funcionalidad útil en este escenario).
clase privada sellada WeatherDataSourceView: DataSourceView {
privado WeatherDataSource _propietario
público WeatherDataSourceView (propietario de WeatherDataSource, cadena viewName)
: base (propietario, nombre de vista) {
_propietario = propietario;
}
anulación protegida IEnumerable ExecuteSelect(
argumentos DataSourceSelectArguments) {
argumentos.RaiseUnsupportedCapabilitiesError(this
Weather WeatherObject = GetWeather());
devolver nuevo Tiempo[] { objetotiempo };
}
Tiempo interno GetWeather() {
cadena zipCode = _propietario.ZipCode;
if (código postal.Longitud == 0) {
lanzar nueva InvalidOperationException();
}
WeatherService meteorService = nuevo WeatherService(código postal);
devolver meteorService.GetWeather();
}
vacío interno RaiseChangedEvent() {
OnDataSourceViewChanged (EventArgs.Empty);
}
}
De forma predeterminada, la clase DataSourceView devuelve falso desde propiedades como CanUpdate y arroja NotSupportedException desde Update y métodos relacionados. Lo único que debe hacer aquí en WeatherDataSourceView es anular el método abstracto ExecuteSelect y devolver un IEnumerable que contenga los datos meteorológicos "seleccionados". En la implementación, se usa una clase auxiliar WeatherService, que simplemente usa un objeto WebRequest para consultar Weather.com (en inglés) usando el código postal seleccionado (no hay nada especial en eso).
Quizás hayas notado que ExecuteSelect está marcado como protegido. Lo que realmente llama el control vinculado a datos es el método Select público (y sellado) pasado en la devolución de llamada. La implementación de Select llama a ExecuteSelect y llama a la devolución de llamada con la instancia IEnumerable resultante. Este patrón es muy extraño. Hay una razón para esto, que se explicará en artículos posteriores de esta serie. Espere...
Aquí hay un ejemplo de este uso:
Código postal: <asp:TextBox runat="server" id="zipCodeTextBox" />
＜asp:Botón runat="servidor" onclick="OnLookupButtonClick" Text="Mirar" /＞
＜hr /＞
＜asp:FormView runat="servidor" DataSourceID="weatherDS"＞
＜Plantilla de artículo＞
<asp:Etiqueta runat="servidor"
Text='＜%# Eval("Temperatura", "La temperatura actual es {0}.") %＞' /＞
＜/Plantilla de elemento＞
＜/asp:FormView＞
＜nk:WeatherDataSource runat="servidor" id="weatherDS" ZipCode="98052" /＞
＜script runat="servidor"＞
privado vacío OnLookupButtonClick (remitente del objeto, EventArgs e) {
tiempoDS.ZipCode = zipCodeTextBox.Text.Trim();
}
</script>
Este código establece el código postal en respuesta a la entrada del usuario, lo que hace que la fuente de datos emita una notificación de cambio, lo que hace que el control FormView vinculado realice el enlace de datos y cambie la visualización.
Ahora, el código de acceso a los datos está encapsulado en el control de la fuente de datos. Además, este modelo permite a Weather.com (en inglés) publicar un componente que también puede encapsular detalles específicos de su servicio. Ojalá funcione. Además, la interfaz de fuente de datos abstracta permite que FormView funcione solo con datos meteorológicos.
En el siguiente artículo, mejorará el control de la fuente de datos para manejar automáticamente los cambios en el valor del filtro (es decir, el código postal) utilizado para consultar los datos.