Info de ADO

Bueno para empezar a comentar algo de ADO.Net pues como todo proceso se empieza por la busqueda de información, asi que en este caso empeze pidiendole a mis amigos Esteban y Ronald (en realidad solo le pedi a Esteban, asi que las disulpas para Ronald, espero no me hagan problemas por derechos de autor o me pidan unas regalias =P) algo de información sobre ADO.Net, porque? el ya lo estudio y tiene algo ordenado, siempre es bueno empezar siempre con un orden, manteniendo una metodologia, asi que empezaremos definiendo los temas que conciernen, algo basico, porque buscar toda la información que existe y estudiarla asi por asi es cometer el error que yo tuve, no se entendia lo que se leia y surgian mas problemas (hasta conflictos personales: porque no entiendo? quizas no soy habil para esto).

Primero que es ADO? para que lo usamos? y ojo que ADO es muy distinto a decir ADO.Net, porque? en realidad ADO.Net vendria a ser la evolucion de ADO. Pero antes de seguir mareandose primero veamos que es ADO, o en que se usa.

ADO (ActiveX Data Objects) es una tecnologia de acceso a datos que brinda las funcionalidades necesarias para acceder y manejar una base de datos, usando unos controles OLEDB. Esta tecnologia es una tecnologia orientada a objetos para componentes ActiveX basada en una API (Application Programmin Interface, disculpen si me equivoco) llamada OLEDB (los controles antes mencionados), evitando la programacion a bajo nivel.

Su entorno estaba diseñado basicamente para manejar en un entorno conectado, es decir, las aplicaciones que recurrian a hacer algo con una DB (database, base de datos) mantenian la conexion "viva", conectada todo el tiempo hasta que se finalizara la operacion. Tambien se podia manejar en un entorno desconectado, o digamos se podia trabajar de manera desconectada, se conectaba solamente para traer la data y se cerraba la conexion, esto mediante el empleo del recordset cuya funcion era ser el "contenedor de datos", una tabla con todos los datos solicitados

La gran aceptacion que tuvo ADO fue que era independiente del lenguaje que se utilizara al acceder (JavaScript, VBScript, etc), permitiendo conectar la pag web a cualquier DB compatible con ODBC a traves de una interfaz basado en objetos; pero no todo era felicidad.... no señores ..... los problemas surgieron al instante, el trabajar de manera conectada puede generar, si bien es cierto, datos actualizados, como "pan caliente", pero el problema es que si miles de usuario piden lo mismo (por ejemplo cuando se solicita un pedido a una empresa distribuidora) la red se congestiona por que tiene que mantener las miles de conecciones vivas, y por ende para el cliente lo que observa es gran demora por hacer quizas una transaccion tan simple para el (como comprar algo) y se llegan a extremos de aburrimiento (con algunas dosis de amargura por querer realizar las cosas en el menor tiempo posible). Ahora si pensamos en un entorno desconectado solo los clientes se conectarian a la DB para extraer la data, almacenarla en el recordset y cerrar la conexion, con esto miles de usuario no estarian ligados o amontonados y se evitaria sobrecargar el servidor, parece todo bien hasta ahora no lo creen?? pero hay un rotundo NO, los problemas surgen cuando se necesita que los datos sean lo mas actuales posibles, como por ejemplo en la bolsa de valores, donde se requiere datos precisos, entonces si tenemos datos obtenidos de manera desconectada y no son actualizados, puede que no se tomen las decisiones correctas. El empleo de ambas formas va a depender de la persona que desarrolle el aplicativo y bajo que circunstancias se trabaja la data, si se necesita que constantemente esta actualizada o no.