Documente Academic
Documente Profesional
Documente Cultură
Pgina 1
Pgina 2
Pgina 3
De los anteriores puntos podemos obtener muy buenas conclusiones en cuanto a las mejoras introducidas en el nuevo modelo ADO .NET. Se puede resumir en un mejor mecanismo de comunicacin entre procesos gracias a XML y una independencia del cliente con respecto al servidor, que posibilita el funcionamiento autnomo de la aplicacin (mejor tolerancia a fallos, independencia del estado de la red).
Interoperabilidad
Las aplicaciones basadas en ADO .NET obtienen ventaja de la flexibilidad y la masiva aceptacin del estndar XML para el intercambio de datos. Puesto que XML es el estndar de envo 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.
Pgina 4
Mantenimiento
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 se trata de una cuestin 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. Una de esas capas es la de datos, que es fundamental desarrollar correctamente. Gracias a los DataSets, 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, convirtindola en ms modular y fcil de mantener.
Programacin
Los programadores pueden acceder a un API de programacin estructurado, de fuerte tipificado y que adems se concentra en la correcta forma de presentar los datos. Centra en la estructura del lenguaje lo que un programador necesita para disear los programas sin dar muchos rodeos. El Cdigo fuente 557 muestra un ejemplo de cdigo sin tipificar:
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. El Cdigo fuente 558 muestra un ejemplo un poco ms tipificado:
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.
Pgina 5
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.
Escalabilidad
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, etc., y una comprobacin de sus permisos; todo ello consume 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. 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.
Una de las mayores ventajas de esta implementacin, es que una vez obtenido 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. Una consecuencia lgica de este tipo de arquitecturas, es la de conseguir que los DataSets sean independientes de los orgenes de datos. Los drivers OLE-DB transformarn la consulta SQL en un cursor representado con una estructura XML, que es independiente del motor de la base de datos. Esto nos permitir trabajar con mltiples orgenes de datos, de distintos fabricante e incluso en formatos que no pertenezcan a bases de datos, por ejemplo, ficheros planos u hojas de clculo, lo que representa un importante punto de compatibilidad y flexibilidad. Si a esto unimos el hecho de que disponemos de un modelo consistente de objetos (xmlDOM) que es independiente del origen de datos, las operaciones de los DataSets no se vern afectadas por dicho origen. La persistencia es un concepto muy interesante en el mundo del desarrollo. Es un mecanismo por el cual un componente puede almacenar su estado (valores de variables, propiedades, datos...en un momento concreto del tiempo) en un soporte de almacenamiento fijo. De manera, que cuando es necesario, se puede recargar el componente tal y como qued en una operacin anterior. En un sistema de trabajo Off-Line como el que plantea ADO .NET, la persistencia es un mecanismo fundamental. Podemos cerrar la aplicacin y mantener persistentes todos los DataSets necesarios, de manera que al reiniciarla, nos encontramos los DataSets tal y como los dejamos. Ahorrando el tiempo que hubiera sido necesario para recuperar de nuevo toda esa informacin del servidor. Optimizando todava ms el rendimiento del sistema distribuido. El formato que emplea ADO .NET para almacenar su estado es XML. Puesto que ya es un estndar de la industria, esta persistencia nos ofrece las siguientes cualidades: La informacin puede estar accesible para cualquier componente del sistema que entienda XML. Es un formato de texto plano, no binario, que lo hace compatible con cualquier componente de cualquier plataforma, y recuperable en cualquier circunstancia.
DataSet
El API de ADO .NET proporciona una superclase, DataSet, que encapsula lo que sera la base de datos a un nivel lgico: tablas, vistas, relaciones, integridad entre todos ellos, etc., pero siempre con independencia del tipo de fabricante que la dise. Aqu se tiene el mejor concepto de datos desconectados: una copia en el cliente de la arquitectura de la base de datos, basada en un esquema XML que la independiza del fabricante, proporcionando al desarrollador la libertad de trabajo independiente de la plataforma. La Figura 339 muestra una representacin de este tipo de objeto.
Pgina 7
Esta clase se compone a su vez, de clases de soporte, que representan cada una, los elementos arquitecturales de la base de datos: tablas, columnas, filas, sus reglas de chequeo, sus relaciones, las vistas asociadas a la tabla, etc.
Pgina 8
Dentro del espacio de nombres System.Data encontramos las siguientes clases compartidas, que constituyen el eje central de ADO .NET. DataSet. Almacn de datos por excelencia en ADO .NET. Representa una base de datos desconectada del proveedor de datos. Almacena tablas y sus relaciones. DataTable. Un contenedor de datos. Estructurado como un conjunto de filas (DataRow) y columnas (DataColumn). DataRow. Registro que almacena n valores. Representacin en ADO .NET de una fila/tupla de una tabla de la base de datos. DataColumn. Contiene la definicin de una columna. Metadatos y datos asociados a su dominio. DataRelation. Enlace entre dos o ms columnas iguales de dos o mas tablas. Constraint. Reglas de validacin de las columnas de una tabla. DataColumnMapping. Vnculo lgico existente entre una columna de un objeto del DataSet y la columna fsica de la tabla de la base de datos. DataTableMapping. Vnculo lgico existente entre una tabla del DataSet y la tabla fsica de la base de datos.
Adems de estas clases, existe otro grupo de clases consistente en las clases especficas de un proveedor de datos. Estas clases conforman los aspectos particulares de un fabricante de proveedores
Pgina 10
Para aquellos conocedores de ADO en alguna de sus versiones anteriores, podemos hacer una analoga o comparacin entre las antiguas clases de ADO y las nuevas de ADO .NET. En la Figura 341 se puede ver esta aproximacin.
Pgina 11
Hasta aqu hemos realizado una introduccin a la tecnologa ADO .NET, repasando su arquitectura y comentando las clases principales. En lo que resta de tema vamos a utilizar las distintas clases que nos ofrece ADO .NET desde VB.NET, para realizar tareas comunes de acceso a datos, como pueden ser establecer una conexin, obtener un conjunto de registros, realizar operaciones con los datos, etc.
Pgina 12
La sintaxis utilizada para indicar la cadena de conexin, con las particularidades propias de cada proveedor, veremos que es muy similar a la utilizada en ADO clsico. El Cdigo fuente 559 muestra un ejemplo de conexin con un servidor SQL Server 2000, y su posterior desconexin, utilizando un objeto SqlConnection. Debemos importar el espacio de nombres Data.SqlClient para poder utilizar el objeto. Este cdigo lo podemos asociar a la pulsacin de un botn en un formulario.
Pgina 13
El Cdigo fuente 560 muestra la misma operacin pero usando el objeto de conexin para el proveedor de OLEDB. Observe el lector las diferencias en las cadenas de conexin y el objeto de excepcin con respecto al anterior ejemplo, as como el espacio de nombres a importar.
Pgina 14
Una vez vistas algunas de las propiedades de las clases SqlCommand y OleDbCommand, vamos a pasar a comentar brevemente los principales mtodos de estas clases. CreateParameter. Crea un parmetro para el que despus podremos definir una serie de caractersticas especficas como pueden ser el tipo de dato, su valor, tamao, etc. Devolver un objeto de la clase SqlParameter u OleDbParameter. ExecuteNonQuery. Ejecuta la sentencia SQL definida en la propiedad ComandText contra la conexin definida en la propiedad Connection. La sentencia a ejecutar debe ser de un tipo que no devuelva un conjunto de registros, por ejemplo Update, Delete o Insert. Este mtodo devuelve un entero indicando el nmero de filas que se han visto afectadas por la ejecucin del objeto Command.
Pgina 15
A continuacin mostraremos algunos ejemplos de uso de objetos Command. El Cdigo fuente 561 ilustra la insercin de un registro utilizando un objeto SqlCommand. En primer lugar utilizamos un constructor de la clase, que recibe como parmetro la sentencia a ejecutar y la conexin. Como vamos a ejecutar una sentencia que no produce un conjunto de resultados, emplearemos el mtodo ExecuteNonQuery( ). Observe tambin el lector en este ejemplo, que la conexin slo permanece abierta en el momento de ejecutar el comando; esta es la tcnica recomendable que debemos utilizar para todas las operaciones con datos: mantener abierta la conexin el menor tiempo posible.
En el Cdigo fuente 562 realizamos tambin la insercin con un SqlCommand, pero utilizando en este caso parmetros. En la cadena que tiene la sentencia SQL indicaremos los parmetros con el formato @NombreParmetro. Para crear cada uno de los parmetros utilizaremos la clase SqlParameter, mientras que para aadir los parmetros usaremos la coleccin Parmeters del objeto SqlCommand y su mtodo Add( ).
Pgina 16
Si empleamos un objeto OleDbCommand, la sintaxis de la sentencia SQL cambia, ya que los parmetros deberemos indicarlos como hacamos en ADO clsico, utilizando el carcter ?. Veamos un ejemplo en el Cdigo fuente 563.
Pgina 17
En el caso de que necesitemos ejecutar un procedimiento almacenado, debemos indicarlo mediante las propiedades CommandType y CommandText del objeto Command que estemos utilizando. En la primera establecemos el tipo de comando (procedimiento almacenado) seleccionando el valor de la enumeracin asociada a la propiedad; y en la segunda asignamos una cadena con el nombre del procedimiento almacenado. El Cdigo fuente 564 muestra un ejemplo, en el que podemos comprobar que hemos utilizado un constructor de SqlCommand sin parmetros, por lo que el objeto Connection lo asignamos despus mediante la propiedad Connection
Pgina 18
Para obtener el resultado de una funcin del lenguaje SQL, por ejemplo Count( ), emplearemos el mtodo ExecuteScalar( ) del objeto Command. En el Cdigo fuente 565, la ejecucin de este mtodo nos devuelve el nmero de filas de una tabla de la base de datos, que mostramos en un mensaje.
Pgina 19
Una vez vistas las propiedades, vamos a comentar los mtodos ms destacables. Close( ). Cierra el objeto DataReader liberando los recursos correspondientes. GetXXX( ). El objeto DataReader presenta un conjunto de mtodos que nos van a permitir obtener los valores de las columnas contenidas en el mismo en forma de un tipo de datos determinado, segn el mtodo GetXXX empleado. Existen diversos mtodos GetXXX atendiendo al tipo de datos de la columna, algunos ejemplos son GetBoolean(), GetInt32(), GetString(), GetChar(), etc. Como parmetro a este mtodo le debemos indicar el nmero de orden de la columna que deseamos recuperar. NextResult( ). Desplaza el puntero actual al siguiente conjunto de registros, cuando la sentencia es un procedimiento almacenado de SQL o una sentencia SQL que devuelve ms de un conjunto de registros, no debemos confundir este mtodo con el mtodo MoveNext() de ADO, ya que en este caso no nos movemos al siguiente registro, sino al siguiente conjunto de registros. Read( ). Desplaza el cursor actual al siguiente registro permitiendo obtener los valores del mismo a travs del objeto DataReader. Este mtodo devolver True si existen ms registros dentro del objeto DataReader, False si hemos llegado al final del conjunto de registros. La posicin por defecto del objeto DataReader en el momento inicial es antes del primer registro, por lo tanto para recorrer un objeto DataReader debemos comenzar con una llamada al mtodo Read(), y as situarnos en el primer registro.
El proyecto PruDataReader (hacer clic aqu para acceder al ejemplo), contiene un formulario con algunos controles, que muestran el uso de objetos DataReader. El botn Empleados crea a partir de un comando, un objeto DataReader que recorremos para llenar un ListBox con los valores de una de las columnas de la tabla que internamente contiene el DataReader. Veamos este caso en el Cdigo fuente 566.
Pgina 20
Como tambin hemos indicado anteriormente, un objeto Command puede estar basado en mltiples sentencias SQL, separadas por el carcter de punto y coma ( ; ), que se ejecuten en lote. Al crear un DataReader desde un comando de este tipo, podemos recorrer el conjunto de consultas mediante el mtodo NextResult( ) del DataReader. Un ejemplo de este tipo lo tenemos al pulsar el botn Clientes/Productos del formulario, cuyo fuente vemos a continuacin en el Cdigo fuente 567. Observe en este caso que conectamos a travs de OLE DB, por lo que empleamos los objetos ADO .NET de esta categora.
Pgina 21
La Figura 342 muestra este formulario despus de haber rellenado los controles ListBox usando objetos DataReader.
Pgina 22