LOS ESPACIOS DE NOMBRES DE ADO.

NET

ADO.NET se encuentra en la biblioteca System.Data.dll, y ofrece clases en cinco
espacios de nombres bien diferenciados que explico brevemente a continuacin

System.Data: es el espacio de nombres primario. Dentro de este espacio de nombres
tenemos un con!unto de clases que representan, di"amos, una base de datos virtual, tablas,
filas, columnas, relaciones, etc. Sin embar"o, nin"una de estas clases ofrece conexin al"una
con un ori"en de datos, sino que simplemente representan los datos en s# mismos.

System.Data.Common: ofrece clases comunes entre distintos or#"enes de datos. $ara
lo que vamos a tratar en este art#culo, podemos decir que estas clases sirven de clase base
para las que est%n contenidas en los dos espacios de nombres que vienen a continuacin.

System.Data.OleDb: contiene una serie de clases que nos permiten conectarnos con
cualquier ori"en de datos e interactuar con &l al tiempo que sirven de 'intermediarios' entre el
ori"en de datos y las clases del espacio de nombres System.Data que, se"(n dec#amos, no
tienen conexin al"una con dic)o ori"en de datos. *as clases de System.Data.OleDb usan
O*ED+ como tecnolo"#a subyacente.

System.Data.SqlClient: contiene clases que permiten interactuar con or#"enes de
datos S,* Server de un modo muc)o m%s directo que O*ED+, me!orando el rendimiento para
este tipo de ori"en de datos. $or lo tanto, solamente se pueden utili-ar para acceder a bases
de datos de S,* Server. El uso de sus clases es pr%cticamente equivalente al de las que se
encuentran en System.Data.OleDb.

System.Data.SqlTypes: este espacio de nombres ofrece los tipos primitivos que usa
S,* Server. Obviamente, aunque se pueden usar los tipos equivalentes del .TS, los que se
incluyen en este espacio de nombres est%n optimi-ados para traba!ar con S,* Server.

A pesar de que el modelo de ob!etos )a sido simplificado, a(n si"ue siendo lo
suficientemente extenso como para no poder entrar en detalle con todas sus clases en slo un
art#culo, sobre todo si no quiere uno a"obiar a los sufridos lectores m%s de lo estrictamente
necesario. $or este motivo, nos centraremos m%s en al"unas clases fundamentales de los
espacios de nombres System.Data y System.Data.Sql.lient, desarrollando para ello un e!emplo
completo. Daremos tambi&n al"una peque/a pincelada con clases OleDb, pero no
reproduciremos un e!emplo completo en este caso porque ser#a casi id&ntico al desarrollado
con Sql.lient.

LAS CLASES BSICAS DE ADO.NET

*as )e llamado b%sicas porque, realmente, ser%n el pilar fundamental para casi
cualquier aplicacin que ten"a que acceder a un ori"en de datos con unos m#nimos requisitos
de eficiencia y escalabilidad. *as clases m%s importantes del espacio de nombres System.Data
son

DataSet: aun a ries"o de equivocarme, dir& que es la piedra an"ular del modelo de
ob!etos Esta lase pe!mite tene! en memo!ia "na a"t#ntia $base %e %atos &i!t"al$, con
sus tablas, relaciones, etc. 0n )ec)o importante es que esta base de datos virtual est% total y
absolutamente desconectada de cualquier ori"en de datos f#sico y, en consecuencia, siemp!e
se alo!a toda entera en la memoria. En otras palabras, puede contener uno o varios con!untos
de filas distintos, que pueden estar o no estar relacionados entre s#, pero siempre en la
memoria y siempre desconectados del ori"en de datos. *a clase DataSet est% dentro del
espacio de nombres System.Data.

DataTable: un DataTable representa un con!unto de filas y columnas tambi&n en
memoria y desconectado del ori"en de datos, como el DataSet. $ertenece al espacio de
nombres System.Data. *a propiedad Tables de un ob!eto DataSet contiene una coleccin de
ob!etos DataTable, y dic)a coleccin es de la clase DataTable.ollection. $or otra parte, cada
ob!eto DataTable representa sus filas en la propiedad 1o2s 3de la clase Data1o2.ollection4,
siendo cada fila, a su ve-, un ob!eto de la clase Data1o2, y sus columnas en la propiedad
.olumns 3de la clase Data.olumn.ollection4, siendo cada columna un ob!eto de la clase
Data.olumn.

DataRelation representa una relacin entre dos ob!etos DataTable. Tambi&n pertenece
al espacio de nombres System.Data. Todas las relaciones que )aya en un DataSet se
encuentran en la coleccin 1elations, de la clase Data1elation.ollection.

.omo podr%s suponer, )ay m%s, pero no ser%n necesarias para el desarrollo de este
art#culo. A)ora, vamos a pasar a ver las clases m%s importantes del espacio de nombres
System.Data.Sql.lient, y sus equivalentes en el espacio de nombres System.Data.OleDb

SqlConnetion: su equivalente en OleDb es OleDbConnetion. Son m%s o menos
equivalentes a la clase .onnection del anti"uo ADO, en tanto en cuanto que proporcionan la
conexin con el ori"en de datos y mantiene al"unas de sus anti"uas propiedades y m&todos,
como son .onnectionStrin", .onnectionTimeOut, Open y .lose. Sin embar"o, al i"ual que las
otras clases que tambi&n tienen un equivalente 3m%s o menos4 en la tecnolo"#a anti"ua, ten
presente que no se mane!an exactamente i"ual, como tendremos ocasin de ver m%s adelante.

SqlComman%: su equivalente en OleDb es OleDbComman%. Tambi&n son parecidos
a los anti"uos ob!etos .ommand de ADO y, como estos, representan procedimientos
almacenados o instrucciones S,* que se e!ecutan en el ori"en de datos.

SqlPa!amete!: su equivalente en OleDb es OleDbPa!amete!. Del mismo modo que
los dos anteriores, se parecen a los ob!etos $aremeter del anti"uo ADO, y representan un
par%metro dentro de la coleccin $arameters del ob!eto Sql.ommand u OleDb.ommand,
se"(n el caso. *a coleccin $arameters de un ob!eto Sql.ommand es de la clase
Sql$arameter.ollection 3OleDb$arameter.ollection en OleDb4.

SqlDataA%apte!: su equivalente en OleDb es OleDbDataA%apte!. Esta clase no tiene
nada parecido 3ni de le!os4 en el anti"uo ADO. .ontiene un con!unto de ob!etos Sql.ommand
3( OleDb.ommand, se"(n proceda4 en sus propiedades Select.ommand, 5nsert.ommand,
0pdate.ommand y Delete.ommand. .uando se invoca el m&todo 6ill, el DataAdapter rellena
un ob!eto DataSet o DataTable con el con!unto de filas resultante de e!ecutar el comando
establecido en su propiedad Select.ommand. .uando se invoca el m&todo 0pdate, el
DataAdapter e!ecuta el comando establecido en su propiedad 5nsert.ommand para a/adir al
ori"en de datos las filas nuevas a/adidas a un DataTable, el comando 0pdate.ommand para
modificar las filas que )ayan sido modificadas en el DataTable y el comando Delete.ommand
para eliminar las filas que )ayan sido eliminadas en el DataTable. $or lo tanto, el DataAdapter
es el nexo que une los ob!etos DataSet y DataTable, totalmente desconectados, con el ori"en
de datos f#sico. Si la conexin estaba cerrada antes de e!ecutar los m&todos 6ill o 0pdate, el
DataAdapter se ocupa de abrir dic)a conexin para efectuar la operacin requerida, cerrando
de nuevo la conexin una ve- que )a terminado. Si la conexin estaba abierta, el DataAdapter
de!a que dic)a conexin si"a abierta despu&s de )aber terminado.

SqlComman%B"il%e!: su equivalente en OleDb es OleDbComman%B"il%e!. Tampoco
)ab#a nada en el anti"uo ADO que )iciera lo que )ace esta clase. Sencillamente se ocupa de
"enerar los ob!etos command necesarios para un determinado DataAdapter, "racias a los
m&todos 7et5nsert.ommand, 7et0pdate.ommand y 7etDelete.ommand.

Aqu# tambi&n tenemos m%s clases, pero tampoco van a )acernos falta para nuestro
e!emplo, de modo que las pasaremos por alto.

1esumiendo un poco todo esto, ADO.NET ofrece un modo de traba!o completamente
desconectado por medio del DataSet, el DataTable y el DataAdapter. En primer lu"ar se car"an
los datos en un DataSet o en un DataTable, el cual se alo!a en la memoria del cliente. 8ste
efect(a los cambios necesarios en el con!unto de datos alo!ado en la memoria sin necesidad de
mantener una conexin persistente con el servidor 3es decir, el ori"en de datos4, con lo cual el
rendimiento aumenta considerablemente. Despu&s, si se desea almacenar los cambios, se
e!ecuta el m&todo 0pdate del DataAdapter para que este )a"a los cambios pertinentes en el
ori"en de datos, manteni&ndose desconectado el DataSet.

+ien es cierto que en ADO tambi&n se pod#a traba!ar de un modo similar usando
1ecordsets desconectados. Sin embar"o esta t&cnica estaba bastante m%s limitada. $ara
"uardar los cambios efectuados en un 1ecordset desconectado )ab#a que utili-ar como
intermediario otro 1ecordset, ese (ltimo conectado. Adem%s, el m&todo 0pdate+atc) efectuaba
las modificaciones pertinentes en el ori"en de datos, pero no ofrec#a tantas posibilidades de
personali-ar el modo de )acerlo como ofrece el DataAdapter de ADO.NET al proporcionarnos
la posibilidad de especificar ob!etos .ommand propios, para las operaciones de insercin,
actuali-acin y eliminacin de filas. Adem%s de esto, como los distintos 1ecordsets del anti"uo
ADO no pod#an relacionarse entre s# no merec#a la pena mantener abierto un 1ecordset con
una sola fila, aunque estuviera desconectado, lo cual )ac#a que fuera m%s dif#cil de encapsular.