Acceso A Datos Con ADO .NET 3.5 (Ejemplo)
Acceso A Datos Con ADO .NET 3.5 (Ejemplo)
Acceso A Datos Con ADO .NET 3.5 (Ejemplo)
a
ec
de
l
Eje
mp
lo
tur
a
Sipnosis
Esta obra sirve como referencia para todo programador que trabaje en la plataforma .NET y necesite
acceso a datos desde sus aplicaciones.
Sirve, adems como texto de base para la preparacin del examen oficial 70-561 (ADO.NET), parte de
las certificaciones MCTS y MCPD de Microsoft
ec
La primera parte del libro muestra los conceptos de ADO.NET relativos a acceso a datos conectados,
desconectado adems del proceso de sincronizacin de ellos con los gestores de bases de datos relacionales.
de
l
Los ltimos captulos cubren las novedades de ADO.NET 3.5 como son LINQ y sus variantes LINQ
to Objects, LINQ to DataSet, LINQ to DataSet, LINQ to SQL y Entity Framework.
lo
www.heviatec.net.
Eje
mp
ec
tur
a
Luarna
ISBN: 978-84-92684-47-2
Eje
mp
lo
de
l
www.luarna.com
Cualquier forma de reproduccin, distribucin, comunicacin pblica o transformacin de esta obra solo puede ser realizada
con la autorizacin de sus titulares, salvo excepcin prevista por la ley. Dirjase a CEDRO (Centro Espaol de Derechos
Reprogrficos, www.cedro.org) si necesita fotocopiar, escanear o hacer copias digitales de algn fragmento de esta obra.
tur
a
ec
de
l
Eje
mp
lo
tur
a
Indice
de
l
ec
lo
Eje
mp
tur
a
de
l
ec
lo
Eje
mp
tur
a
de
l
ec
Eje
mp
lo
tur
a
ec
Visual Studio .NET 2005 y los servicios de datos (I) .................................................................... 248
Un IDE completamente renovado ................................................................................................ 248
Diseando la capa de datos: Data Designer .................................................................................. 251
Orgenes de datos. Comenzando con planificacin ............................................................... 252
Data Source Explorer .............................................................................................................. 254
El Diseador de datos (Data Designer) .................................................................................... 258
TableAdapter Configuration Wizard ........................................................................................ 260
Ampliando la funcionalidad de un adaptador ....................................................................... 263
La infraestructura de la arquitectura......................................................................................... 265
Agregar nuevos orgenes a un componente ya configurado ...................................................... 266
Establecer relaciones en la lgica de datos ............................................................................... 267
Otras herramientas del entorno .................................................................................................... 268
de
l
Visual Studio .NET 2005 y los servicios de datos (II): WinFORMS............................................ 271
Vnculo a datos desde WinForms ................................................................................................ 271
Preparar el entorno de la demo .................................................................................................... 272
Vincular controles a datos sin esfuerzo. Formularios sencillos. ................................................ 273
Modificar el diseo del formulario .......................................................................................... 275
Formularios Maestro-Detalle ....................................................................................................... 276
Vinculacin avanzada de datos en Windows................................................................................ 281
Parmetros en consultas de datos ............................................................................................. 281
Personalizacin avanzada de DataGridView: Imgenes. .......................................................... 284
Personalizacin avanzada DataGridView: columnas multi-evaluadas....................................... 286
Vincular origen de tipo Objeto a proyectos Windows .............................................................. 288
Consideraciones finales ............................................................................................................... 292
mp
lo
Visual Studio .NET 2005 y los servicios de datos (III): ASP.NET ............................................... 294
Vnculo a datos desde ASP.NET ................................................................................................. 294
El entorno de ASP.NET .............................................................................................................. 295
Formularios sencillos enlazados a datos ...................................................................................... 296
Formularios basados en parmetros ............................................................................................. 298
Formulario maestro-detalle ......................................................................................................... 299
Otros controles de datos, con ms opciones ................................................................................. 303
Un caso particular ................................................................................................................... 304
Y para terminar... ........................................................................................................................ 305
Eje
tur
a
de
l
ec
mp
lo
Eje
tur
a
ec
Eje
mp
lo
de
l
P g i n a | 10
tur
a
ec
de
l
lo
ADO.NET 2.0
Introduccin
mp
.NET es una tecnologa ya ms que asentada. Durante casi 2 aos ha estado subiendo del podio de la
novedad al escaln de la necesidad. Para cualquier tipo de proyecto, .NET se ha convertido en una
herramienta ms que valorada y de la que un alto porcentaje de negocios ya no pueden prescindir.
Durante 2 aos ha demostrado ser lo robusta y efectiva que es, recibiendo el apoyo total de todos los
que estamos implicados en los departamentos de TI.
Eje
Durante estos 2 aos de vida, la maquinaria de Microsoft no ha dejado de trabajar y pensar. .NET no
se estanca y no hace ms que crecer. Podramos considerar estos dos aos como un periodo de gestacin que ya llega a su madurez. Y el fruto de ese cambio de adolescente a adulto se plasma con la nueva versin de estas herramientas: .NET 2.0. Y esa madurez nos trae una enorme cantidad de novedades que realmente justifican este cambio de versin.
Cambios en todos los niveles del framework, fruto de un estudio profundo de lo existente, y una captura intensiva de nuevos requisitos en las que hemos estado implicados todos nosotros. Desde el propio motor del CLR, pasando por la adicin de numerossimas clases nuevas, reestructurando por completo el motor de ASP.NET hasta llegar a la evolucin de uno de los mejores editores de desarrollo
del mundo: el flamante Visual Studio 2005.
De todas estas novedades, os iris empapando a lo largo de toda la serie de textos que se os ofrecer en
nuestra editorial. Por la parte que me toca, me centrar en uno de los temas que a todos nos apasionan
P g i n a | 11
tur
a
y que son pieza estructural bsica de todo sistema de informacin: las herramientas de la capa de datos. Y que mejor que el nuevo ADO.NET 2.0 para abordar esas tareas
En el presente texto, hablaremos del modelo de clases de ADO.NET 2.0, pero haciendo un fuerte repaso de aquel modelo que ya se planteaba desde ADO.NET 1.1, como no puede ser de otra forma. Si, ya
existen libros incluso de este autor- que hablan de ADO.NET 1.1. Entonces para qu hablar otra
vez de lo mismo pues la razn es que hay novedades incluso en el modelo de clases que ya conocemos, por eso ser bueno que repasemos y ampliemos.
Pues nada, pasamos a ver a vista de pjaro la lista de cambios y pasamos ya a la chicha
ec
de
l
ADO.NET 1.1 ya signific un cambio importante respecto al modelo planteado por las tecnologas
pre.net (ADO, OLE DB, COM). ADO.NET 2.0 no es un cambio tan trascendental, ms bien es una
renovacin basada en la madurez de la arquitectura anterior. Y en todo proceso de madurez siempre
aparecen nuevas formas de hacer las mismas cosas adems de mejorar aquellas existentes. Se asientan
las que ya funcionaban, se revisan las que podan mejorarse y se definen nuevas estrategias para
abordar ms y ms complejos contextos -Esta sera la mejor definicin del modelo de ADO.NET 2.0-.
Si comparamos ambas arquitecturas, podremos sacar las siguientes conclusiones:
Lo que funciona no lo toques
El modelo de clases de ADO.NET 1.1 ya cubra un extenso conjunto de posibles contextos. Pero a veces en casos concretos no era tan
preciso tanto en funcionalidad como en diseo. As que en
ADO.NET 2.0 se amplan las funcionalidades de las clases conocidas, para dotarlas de ms precisin en esos casos concretos. El
mismo camino con la mitad de cdigo. No os confiis pues, ya que
las clases que ya conocis han mejorado. De todo se aprende.
lo
mp
Eje
P g i n a | 12
Empleando patrones de diseo y aprovechando tecnologas ya presentes en el framework, se ofrece la posibilidad de acceder a cualquier proveedor de datos de forma abstracta. Esto es, que podemos
escribir cdigo conectado con independencia del proveedor de
datos.
DataTable se independiza
DataSet es un objeto verstil como pocos en el mundo de la informtica. Pero el problema es que en muchos contextos se vuelve
demasiado pesado. Es por esto que ha decidido ampliar la familia:
DataTable se convierte en otra pieza de responsabilidad, pudiendo
vivir fuera del nido con la misma potencia que su padre: la capacidad de serializarse. Lo que lo convierte en una isla de datos de
fcil portabilidad que reduce la carga de recursos y el ancho de
banda en las comunicaciones. Esto claro, posibilita que el propio
framework de ADO.NET abuse de este objeto cuando antes lo haca
de DataSet. Llevando a nuevas sobrecargas del API ya conocido.
de
l
ec
tur
a
Nuevas herramientas
lo
mp
Eje
Rendimiento
Optimizacin
P g i n a | 13
tur
a
ec
de
l
lo
Y esto es slo el principio. Si alguien pensaba que los cambios de ADO.NET 2.0 eran mnimos, que se
agarre los machos, que tenemos muchas cosas que ver.
Beneficios de ADO.NET
mp
ADO.NET 2.0 ofrece una buena cantidad de mejoras respecto a modelos anteriores de ADO y
ADO.NET. Los beneficios los podremos agrupar en las categoras:
Mejor Interoperabilidad
Eje
Las aplicaciones basadas en ADO.NET recogen la ventaja de la flexibilidad y la masiva aceptacin del estndar XML para el intercambio de datos. Puesto que XML es el estndar de envin de informacin entre capas, cualquier componente capaz de Interpretar los datos XML
puede acceder a la informacin de ADO.NET se encuentre donde se encuentre, y procesarla.
Adems, puesto que la informacin se enva en flujos de XML, no importa la implementacin
empleada para enviar o recoger la informacin as como la plataforma empleada-. Simplemente se exige a los componentes que reconozcan el formato XML empleado para el proceso,
envo y recepcin de un Dataset.
P g i n a | 14
tur
a
En ADO.NET ahora incluso es posible emplear el nuevo modelo de DataTable para serializar
la informacin. Puesto que se almacena informacin ms concreta, se pueden abordar muchos
ms contextos ms optimizados que en la versin anterior. En lugar de cachear todo un Dataset, slo necesitaremos cachear aquellas tablas que se requieren. Por lo tanto, un modelo
de datos ms granular y por lo tanto ms optimo.
Mantenimiento
ec
En el ciclo de vida de una aplicacin los cambios poco sustanciales y modestos son permisibles. Pero cuando es necesario abordar un cambio estructural o arquitectnico del sistema, la
tarea se vuelve demasiado compleja y a veces inviable. Esto es una gran desventaja de los sistemas actuales, pues muchas veces esto es una necesidad de actualizacin de los procesos de
la propia empresa. Adems, cuanto ms se aumenta el proceso de la operativa de la empresa,
las necesidades de proceso crecen hasta desbordar las mquinas. Es por ello que se separa la
estructura de un programa en varias capas. Un de esas capas es la de datos, que es fundamental
desarrollar correctamente. Gracias a los Datasets/DataTables, la tarea de portar y aumentar los
procesos de datos y de negocio ser mas sencillo: el intercambio de informacin a travs de
XML, hace que sea ms sencilla la tarea de estructurar en ms capas la aplicacin, lo que la
hace mucho ms modular y mantenible.
de
l
lo
Los programadores pueden acceder a un API de programacin estructurado, fuertemente tipificado y que adems se centra en la correcta forma de presentar las cosas. Centra en la estructura del lenguaje lo que un programador necesita para disear los programas sin dar muchos
rodeos. Un ejemplo de cdigo sin tipificar:
mp
Como se puede observar, aparecen nombres de objetos genricos del sistema que complican la
lectura del cdigo, a la par que los operadores complican tambin la visin de la secuencia de
acceso a los datos. Podramos interpretar lo que hace gracias a que aparecen los nombres propios de los datos que necesitamos....Veamos un ejemplo, un poco ms tipificado:
Eje
El ejemplo es exactamente igual al anterior, pero en este caso, el cdigo se centra ms en los
objetos reales que en el objeto del lenguaje en s: las palabras Table y column ya no aparecen. En su lugar vemos que aparecen los nombres de los objetos empleados de la vida real,
lo que hace el cdigo ms legible. Si a esto unimos que los entornos ya son capaces de ayudarnos a escribir el cdigo, todava lo tenemos ms sencillo, ya que podemos ver con nuestras
palabras el modelo de objetos de datos que necesitamos en cada momento. Incluso a nivel de
ejecucin nos vemos respaldado por un sistema de control de tipos y errores que nos permitirn proporcionar una robustez innata que antes no se tena sin pasar por el uso de funciones externas.
P g i n a | 15
tur
a
En el nuevo API de ADO.NET 2.0, incluso podremos mapear columnas, encapsular llamadas
a procedimientos externos, conectar con mltiples orgenes de datos, etc.
Rendimiento
Puesto que trabajamos con objetos de datos desconectados, todo el proceso se acelera, ya que
no tenemos que estar comunicndonos por Marshalling con el servidor. Adems, gracias al
modelo de XML la conversin de tipos no es necesaria a nivel de COM. Se reduce pues el ancho de banda disponible, se independiza ms el cliente del servidor y se descarga ms a ste,
que puede estar dedicado a otras tareas en lo que el cliente analiza sus datos.
ec
de
l
Escalabilidad
mp
lo
Las aplicaciones Web tienen un nmero ilimitado de conexiones potenciales debido a la naturaleza de internet. Los servidores son capaces de atender muy bien decenas y decenas de conexiones. Pero cuando hablamos de miles y millones, los servidores ya no son capaces de realizar correctamente su trabajo. Esto es debido a que por cada usuario se mantiene una memoria de proceso y conexin, un conjunto de bloqueos de recursos como puedan ser tablas, ndices... y una
comprobacin de sus permisos. Lo que lleva su tiempo y recursos. ADO.NET favorece la escalabilidad puesto que su modelo de conexin Off-Line evita que se mantengan los recursos reservados ms tiempo del considerado necesario. Y esto permite que ms usuarios por unidad de
tiempo puedan acceder a la aplicacin sin problemas de tiempos. Adems se pueden montar servicios en Cluster de alta disponibilidad que sern balanceados automticamente por el sistema
sin afectar a las conexiones ADO. Lo cual garantiza la ampliacin del servicio sin representar un
cambio de arquitectura de diseo.
Eje
P g i n a | 16
tur
a
Con ADO.NET se consigue estar conectado al servidor slo estrictamente necesario para realizar la
operacin de carga de los datos en el dataSet. De esta manera se reducen los bloqueos y las conexiones a la mnima expresin. Se pueden soportar muchos ms usuarios por unidad de tiempo y disminuyen los tiempos de respuesta, a la par que se aceleran las ejecuciones de los programas.
ec
Pero... qu ocurre con aquellas aplicaciones que DEBEN estar conectadas a la base de datos por su
diseo y situacin de proceso? Por ejemplo, una aplicacin de alquiler de pelculas, o un sistema de
venta de Stock... necesitan conocer en todo momento el estado de la base de datos. Y por ello requieren una conexin permanente con la BDD. Pues en ese caso, se continuar utilizando el modelo de
objetos de ADO.NET conectado. Pero en el API de ADO.NET 2.0 se cubre mucho mejor el hueco que
existe entre los dos modos de funcionamiento: el desconectado y el conectado. Gracias al nuevo modelo de Adaptadores y las funcionalidades de replicacin, es posible mantener sistemas semidesconectados que aprovechan lo mejor de los dos mundos, casi sin desarrollar cdigo.
de
l
De toda la vida, el recoger informacin de una base de datos ha ido destinado a realizar un proceso con
dicha informacin: mostrarla por pantalla, procesarla o enviarla a algn componente. Frecuentemente,
la aplicacin no necesita una nica fila, sino un buen conjunto de ellas. Adems, tambin frecuentemente, ese conjunto de filas procede no de una tabla sino de una unin de mltiples tablas (join de
tablas). Una vez que estos datos son cargados, la aplicacin los trata como un bloque compacto. En un
modelo desconectado, es inviable el tener que conectar con la base de datos cada vez que avanzamos
un registro para recoger la informacin asociada a ese registro (condiciones del join). Para solucionarlo, lo que se realiza es almacenar temporalmente toda la informacin necesaria donde sea necesario y
trabajar con ella. Esto es lo que representa un Dataset en el modelo ADO.NET.
mp
lo
Un DataSet es una cach de registros recuperados de una base de datos que acta como un sistema de
almacenamiento virtual, y que contiene una o ms tablas basadas en las tablas reales de la base de
datos. Y que, adems, almacena las relaciones y reglas de integridad existentes entre ellas para garantizar la estabilidad e integridad de la informacin de la base de datos. Muy importante es recalcar, que
los Datasets son almacenes pasivos de datos, esto es, que no se ven alterados ante cambios subyacentes de la base de datos. Es necesario recargarlos (FillDataSet) siempre que queramos estar al da en
cuanto a datos se refiere.
Eje
Una de las mayores ventajas de esta implementacin, es que una vez recogido el dataset, ste puede
ser enviado en forma de flujo XML- entre distintos componentes de la capa de negocio como si de
una variable ms se tratase, ahorrando as comunicaciones a travs de la base de datos.
Pero la clase DataSet es una clase que potencialmente puede consumir muchos recursos. En su modelo de clases y como toda buena base de datos- es posible subdividir su complejidad en clases ms
pequeas. Es por esto que al igual que una base de datos se compone de tablas, un Dataset se componga de DataTables. Pero la novedad no est ah, sino en proporcionar nuevas funcionalidades que perP g i n a | 17
tur
a
miten evolucionar DataTable y colocarlo al mismo nivel funcional que DataSet. Esto es, que DataTable se puede serializar y puede ser utilizado de forma autnoma, sin requerir el uso completo de la
clase Dataset contenedora. Eso si, siguen siendo partes constitutivas, lo cual quiere decir que siguen
conviviendo juntos como hasta ahora pero con la salvedad de que ahora DataTable es mayor y es
capaz de vivir por su cuenta cuando sea menester.
ec
Una consecuencia lgica de este tipo de arquitecturas, es la de conseguir que los objetos desconectados sean independientes de los orgenes de datos. Los drivers OLE-DB, los proveedores .NET, etc.
transformarn la consulta SQL en un Cursor representado con una estructura XML, que es independiente del motor de la base de datos. Es ms, si encima encapsulamos toda la capa de datos en cmodos procedimientos almacenados, ni siquiera necesitaremos integrar el cdigo SQL en la capa de negocio, lo cual todava independiza ms el DataSet/DataTable de la base de datos (ya que el cdigo
SQL, actualmente no es tan estndar...).
de
l
Esto nos permitir trabajar con mltiples orgenes de datos, de distintos fabricante e incluso no-base de
datos - como por ejemplo ficheros planos u hojas de clculo -... lo que representa un importante punto
de compatibilidad y flexibilidad.
Si a esto unimos que disponemos de un modelo consistente de objetos (xmlDOM) que es independiente del origen de datos, las operaciones -y toda su potencia- de los Datasets/Datatables no se vern afectadas por dicho origen.
lo
mp
Es un formato de texto plano, no binario. Que lo hace compatible con cualquier componente
de cualquier plataforma y recuperable en cualquier caso
Eje
P g i n a | 18
tur
a
Muchas veces necesitamos conocer el cmo se estructura un Dataset para poder averiguar qu columnas tenemos disponibles, con qu tipo de datos, tamao, etc. A esta informacin que define el cmo se
estructura la informacin de le denomina Metadatos(Datos que definen datos).
En el caso de los documentos XML, el que determina la estructura que stos tienen son los Esquemas.
No son necesarios para la codificacin del documento XML, pero refuerzan su estructura a la par que
establece una manera comn de introducir nuevos datos respetando un juego de reglas bsico, que toda
aplicacin debe respetar si quiere mantener intacta la integridad del documento original.
de
l
ec
En ADO.NET la generacin de los esquemas as como de los documentos XML asociados a una base
de datos son automticos y transparentes al usuario. No se necesitar acceder a ellos a bajo nivel, a
menos que sea requisito del diseo. Dichos esquemas se actualizarn cuando se modifique la base de
datos o las consultas empleadas para acceder a los datos. Lo dicho, todo transparente al usuario. Y
proporcionarn toda la informacin necesaria para leer la estructura del dataset (que corresponder con
la estructura fsica de la base de datos). Todo un invento.
Eje
mp
lo
P g i n a | 19
tur
a
Aunque parezca un poco galimatas, se puede observar que en documento XML se pueden observar las caractersticas de la tabla sin necesidad de contar con el Enterprise Manager: Las estructuras
element que definen la tabla y los campos de la tabla, las estructuras key que definen claves primarias
y las estructuras complexType que permiten agrupar tipos simples en estructuras de ms alto nivel.
Componentes de ADO.NET
mp
lo
de
l
ec
Veamos una ilustracin del modelo de componentes que plantea Microsoft en su arquitectura .NET
(imagen obtenida de la MSDN de Microsoft):
Eje
Componente
Descripcin
Dataset
DataTable
Dataset command
P g i n a | 20
tur
a
Tabla 1
Como se puede observar, los datos son recogidos del servidor por los componentes DataSetCommand
mediante la ejecucin de comandos SQL (procedimientos almacenados, vistas, consultas...) en el
componente de negocio por los objetos DataSets. Empleando la interfaz XML, estos componentes
entregan la informacin al nivel de interfaz de usuario, que a travs de entornos WEB, formularios
estndar de Windows o bien herramientas especializadas pueden ya procesar y analizar la informacin.
Y a modo de ejemplo, en la capa de interfaz de usuario:
Descripcin
WebForms2
WinForms3
BizzTalk4
Conjunto de herramientas cliente- servidor que permiten automatizar los procesos de negocio.
ec
Componente
de
l
Tabla 2
En los siguientes temas, se proceder a la documentacin de las distintas clases .Net dedicadas a las
tareas de recuperacin de los datos y que estn recogidas en las libreras:
Descripcin
System.Data
Espacio de nombres que integra la gran mayora de clases que habilitan el acceso
a los datos de la arquitectura .NET
System.Data.Common
Contiene las clases compartidas para los .NET Providers5 (proveedores .NET).
Proporcionan la coleccin de clases necesarias para acceder a una fuente de datos
(como por ejemplo una Base de Datos).
System.Data.SqlClient
Espacio de nombres que permite el acceso a proveedores SQL Server en su versin 7.0 y superior. Este espacio de nombres ha sido ampliado para soportar las
nuevas caractersticas de SQL Server 2005.
System.Data.Sql
mp
lo
Nombre de la clase
System.Data.OleDB
Espacio de nombres que permite acceder a proveedores .NET que trabajan directamente contra controladores basados en los ActiveX de Microsoft
System.Data.Odbc
Espacio de nombres que contiene las clases que actan de pasarela con el modelo
de drivers ODBC de Windows. Emplean InterOp para acceder a los drivers nativos ODBC, pero proporcionan un marco de compatibilidad hacia atrs muy importante para muchos fabricantes de SW.
System.Data.Oracle
Eje
WebForms y Winforms se analizan en el texto de EIDOS dedicado al frameWork de desarrollo de Visual Studio .NET
3
ver (1)
P g i n a | 21
tur
a
sos de sistemas gestores de Oracle. Dependen del cliente nativo de Oracle instalado en la mquina. Es recomendable que accedis a la web del fabricante para
acceder a versiones ms actualizadas y desarrolladas por el propio fabricante.
System.Data.Internal
System.Data.SqlTypes
ec
Tabla 3
de
l
lo
Los proveedores gestionados Managed Providers o .NET Providers- de datos hacen referencia a
los mecanismos por los cuales un programa puede acceder a los recursos de un servidor de bases de
datos. Son el conjunto de componentes que interactan como mediadores para independizar el programa de la base de datos. En trminos ya conocidos, son el equivalente a la arquitectura OLE-DB de
Microsoft. Un conjunto de componentes que encapsulan el acceso, manejo de cursores y comunicaciones a un servidor de datos. En el caso de ADO.NET los proveedores gestionados estn encapsulados en un conjunto de clases que, precisamente, hacen transparente al programador el acceso a los
recursos de los drivers de acceso a un servidor de datos. Son el modelo de clases del API de programacin de un origen de datos.
mp
De ah que en la tabla anterior nos encontremos con clases especficas de algunos fabricantes como es
el case de System.Data.SqlClient, que encapsula toda la potencia y flexibilidad de la API de SQL Server. De esta manera el acceso a los datos es ms directo y no se requiere de multitud de componentes
intermedios para realizar una accin, ni perder funciones especficas por compatibilidad con otras
plataformas.
En la plataforma .NET se ofrecen con el SDK, los proveedores gestionados:
SQL Managed Provider. Ofrece el conjunto de clases necesarias para comunicarse con los
comandos de SQL Server en su versin 7.0 superior. Especial hincapi en que este espacio
de nombres ha sido evolucionado para soportar las nuevas tecnologas de SQL Server 2005,
que no son pocas. Lo que se conoce se mantiene, pero investigar las novedades que son extremadamente potentes.
Eje
OleDB Managed Provider. Ofrece el conjunto de clases necesarias para acceder fuentes de
datos accesible a travs de drivers OLEDB/ODBC. En las mejoras de ADO.NET 2.0 el haber
ampliado el soporte que el CLR da a estos tipos de proveedores, como por ejemplo la integracin mejorada de la seguridad, el pool de conexiones, etc.
ODBC Managed provider. Conexiones con el modelo de drivers de la pasarela ODBC nativa
de Windows. No se garantiza en todos los casos el mismo soporte por parte del CLR, pero se
P g i n a | 22
tur
a
ORACLE Managed Provider. Portado de la versin ADO.NET 1.1. Extendido para garantizar la compatibilidad con el cliente de Oracle en su versin 9. Si necesitis soporte para versiones superiores, ser bueno ir a la web de la propia Oracle o emplear sus homlogos
ODBC/OLEDB.
ec
Toda clase que aspire a .NET Provider, debe cumplir que en su espacio de nombres implemente las
clases derivadas de:
Connection. Que ser la clase encargada de encapsular toda la funcionalidad de conexin a
las fuentes de datos.
DataReader. Que contiene todo el subsistema de lectura de los cursores resultados de una
Query
DataAdapter. Que es el componente encargado de adaptar el conjunto de operaciones realizadas desde un origen genrico (por ejemplo, un dataSet) hacia un destino (un servidor de bases de datos relacionales concreto, por ejemplo SQL Server) y viceversa.
mp
lo
de
l
Eje
SqlCommand
SqlDataReader
SqlDataAdapter
P g i n a | 23
tur
a
Actualmente estn en fase final los proveedores gestionados de SQL Server (SQL Managed Providers)
y los de para el acceso a todo el soporte de datos fabricado sobre las especificaciones de OLE-DB,
Microsoft proporciona el conjunto de clases de ADO.NET que tiene compatibilidad con los proveedores de datos OLE-DB (ADO Managed Providers):
SQLOLEDB
MSDAORA
JOLT
MSDASQL/SQLServer ODBC
MSDASQL/Jet ODBC
de
l
ec
Tabla 4
lo
mp
En ADO.NET 2.0 se ha evolucionado el modelo de los proveedores de tal forma que no slo contemos
con conexiones con proveedores concretos conocidos de antemano, sino que adems podamos en
tiempo de ejecucin elegir el proveedor que necesitamos. Esto facilita la generacin de arquitecturas
de SW o productos DataProvider agnostics es decir, independientes del proveedor.
No es que no fuera posible en versiones anteriores, pero las herramientas que se proporcionaban no
iban encaminadas a estos menesteres. Casi se sugera que era responsabilidad del programador el crear
un modelo de servicio para hacer el cdigo ms abstracto, no haciendo fcil la cara dinmica de clases
como si era factible hacer en los modelos de los antiguos OLEDB a travs de la cadena de conexin.
Eje
El caso, es que todo apuntaba a poder implementar un modelo independiente del proveedor, pero al
final la complejidad de anlisis y su puesta en produccin apostaba a por modelos ms sencillos, en los
que era el propio desarrollador el que se montaba la capa de servicios de datos y la reemplazaba en el
caso de cambiar de sistema gestor.
Pero en la versin 2.0 de ADO.NET se ha escuchado a todos los desarrolladores que demandaban esta
funcionalidad. Y se ha implementado de una forma muy elegante, siendo una opcin ms en el SDK
que no estorba, pero que se puede utilizar para mejorar el cdigo o abordar estos contextos, sin modificar todo lo ya conocido. A travs de los principios de abstraccin y la carga dinmica de clases, podremos generar cdigo independiente del sistema gestor. Pero ya lo veremos en su momento.
P g i n a | 24
tur
a
Para acabar con esta somera introduccin a lo que trataremos en este texto, no poda dejar de lado al
nuevo participante en las tecnologas corporativas: SQL Server 2005. Un nuevo producto de Microsoft
que no ha sido slo un lavado de cara del ya soberano SQL Server 2000. Rediseado desde cero, se ha
puesto al da con las nuevas tecnologas y ofrece ciento de novedades que harn nuestros aplicativos
corporativos mucho ms productivos que nunca.
No es plan dedicar este texto a SQL Server 2005, pues ya hay otros autores que estn con ello, pero no
puedo evitar hablar del tema, ya que va de la mano de las mayores mejores de las clases de ADO.NET.
ec
En SQL Server 2005 podemos decir que existen tres grandes bloques que afectan a ADO.NET:
a) Los nuevos API, frameworks y servicios de SQL Server 2005. Como, por ejemplo, Notification Services, Service Broker, etc. Que obviamente ofrecen multitud de herramientas para
simplificar ciertos contextos corporativos a la mnima expresin.
de
l
b) Las nuevas caractersticas del CORE de SQL Server 2005. Que hacen que el servidor
ofrezca mejores herramientas, y un lenguaje TSQL ms potente y con ms funcionalidad que
el anterior. A la par que .NET se embute en el propio CORE, dando al desarrollador la oportunidad de desarrollar objetos de datos empleando esta tecnologa: procedimientos almacenados, funciones incluso nuevos tipos de datos.
Eje
mp
lo
c) Las nuevas caractersticas del servidor de administracin. Lo cual llevar a los desarrolladores a interactuar de un modo ms concreto con todo el motor de la base de datos, automatizando virtualmente cualquier tarea del sistema gestor. A la par que hay ms y mejores herramientas de tolerancia a fallos, alta disponibilidad, etc., que permitir el desarrollo de sistemas
ms robustos que nunca, con la mnima interaccin por parte del desarrollador.
Figura 6. SQL Server Enterprise Manager y los interfaces de programacin de una BDD
P g i n a | 25
tur
a
En el presente texto haremos mencin del apartado (b). Los dems, los dejaremos para el autor de
SQL Server que tiene tambin muchas cosas que contar.
Una de las mayores novedades de ADO.NET 2.0 est en el nuevo soporte que da para la construccin
de capas de datos. Entendiendo por capa de datos la abstraccin lgica que montamos para independizar una capa lgica de aplicacin de capas de ms bajo nivel. Para esto, ADO.NET ofrece dos nuevos
frameworks de encapsulacin de la capa de datos:
ec
de
l
b) Una arquitectura de acceso a datos basada en los esquemas de datos. Totalmente integrado con VS 2005, la posibilidad de generar una capa de acceso a datos totalmente encapsulada
en clases, basada en la descripcin del modelo de datos a partir de esquemas XSD. A partir de
dicho esquema XSD, se genera el cdigo necesario para dar al desarrollador todas las herramientas que demande para navegar y manipular los datos. Y poder cambiarlo en cualquier
momento, simplemente accediendo al esquema y aadiendo o quitando funcionalidad. Y, como no, integrado con toda la tecnologa de DataBinding. Lo veremos, una maravilla. Que dejemos claro a muchos gustar a otros no. Pero aqu lo dejamos caer.
lo
Para que no tengis que picaros todos los fuentes a mano, podris decargar todos los proyectos realizados en el texto en la siguiente URL:
http://www.elcampusdigital.com/FtpTextos/AdoNet2/FuentesADONET2.zip
mp
En todos los captulos, debajo del cdigo fuente tendris especificada la carpeta del proyecto del que
se est hablando en cada momento.
Eje
Bien, pues despus de este pedazo de presentacin creo que es momento de entrar de lleno en el
nuevo ADO.NET 2.0. Manos a la obra.
P g i n a | 26