Artículo escrito por
Antonio Castaño, Microsoft Visual FoxPro - MVP y publicado en la revista del MUG (MS Users Group de Argentina) en el mes de Junio de 2000.
Nota del Editor:
Este artículo fue escrito por Antonio Castaño, Microsoft Visual FoxPro - MVP y publicado en la revista del MUG (MS Users Group de Argentina) y publicado en el mes de Junio de 2000. Cabe aclarar que algunos temas y vínculos pueden estar desactualizados.
Introducción
De todas las tecnologías que han surgido en los últimos tiempos, ADO es una de las más interesantes y una de las que se utiliza en mayor cantidad de productos y herramientas de la familia Microsoft.
Y como se trata de una tecnología específica de acceso a datos, es de especial interés para los desarrolladores Visual FoxPro.
El objetivo de este artículo es destacar algunos características de especial interés para quienes usamos Visual FoxPro como principal herramienta, y comentar algunas particularidades de su uso. No se pretende en este corto espacio, desarrollar todas las características y funcionalidades de ADO. Existe una gran cantidad de documentación, artículos y libros sobre la materia, algunos de los cuales se mencionan en el título
Referencias.
Algunas definiciones
La tecnología ADO (Active Data Objects) forma parte de la estrategia definida por Microsoft para acceso a datos (UDA: Universal Data Access), que se implementa a través del sucesor de ODBC, OLE DB (más información:
http://www.microsoft.com/data).
ADO es un conjunto de clases que se instalan en cualquiera de las versiones de Windows de 32 bits, y sus objetivos son:
- Proveer acceso a datos independientemente de su formato y/o ubicación
- Proveer una interfaz basada en objetos a OLE DB, a través de un modelo de objetos simple y flexible
- Que pueda ser usado desde cualquier lenguaje / entorno que permita trabaja con objetos COM/ActiveX
ADO y Visual FoxPro
En su versión actual, VFP no cuenta con mecanismos específicos de RAD (Rapid Application Developement) para hacer uso de ADO, pero al ser ADO un conjunto de clases COM, pueden ser utilizado en su funcionalidad completa sin ningún problema.
Si bien otras herramientas de Visual Studio (VB, VI) cuentan con algunos componentes RAD específicos para hacer uso de la funcionalidad de ADO, los desarrolladores de cualquiera herramienta que deban encarar la tarea de hacer código robusto y realmente reutilizable, deberán recurrir al uso programático de ADO, tal cual se hace en Visual FoxPro.
Visual FoxPro tiene la natural características de ser una herramienta ideal para construir aplicaciones basadas en componentes, gracias a su rica implementación de programación orientada a objetos (OOP).
Es por eso que para los desarrolladores VFP, ADO, al ser una tecnología basada en objetos, abre todo un mundo de posibilidades. Uno de los fuertes de Visual FoxPro, dentro del espectro de herramientas de Visual Studio, es el desarrollo de componentes de negocio en los que sea crítica la habilidad para obtener y manipular datos. La posibilidad de utilizar esta tecnología para el intercambio de información entre estos componentes, ofrece nuevas alternativas para implementar soluciones robustas y flexibles.
Por otra parte, cabe destacar que, al haber sido ADO desarrollado por integrantes del equipo que desarrolló Visual FoxPro, con el objeto de aprovechar la excepcional tecnología de manejo de cursores que tiene VFP, existen una cantidad de conceptos y hasta de terminología, que resultarán familiares.
Manos a la obra...
Para trabajar con ADO, es importante instalar el Service Pack 3 de Visual Studio. Este SP, además de solucionar una lista importante de bugs, mejora los mecanismo para las comunicaciones a través de COM. Por ejemplo, con la aplicación de este SP, VFP es un “mejor ciudadano” corriendo bajo MTS (Microsoft Transaction Server), y permite construir multithreaded dlls. Otro de los efectos visibles de estas mejoras, es que teniendo aplicado el SP3 es posible utilizar controles ActiveX que permitan su asociación (“boundeo”) a recordsets de ADO (ej: Microsoft Hierarchical Flex Grid, o Protoview TreeViexX).
Otro componente que es conveniente instalar para trabajar con ADO, es una .dll que se publicó con posterioridad a la salida de la versión 6, pero que no está incluida en el Service Pack 3. Se trate de
vfpcom.dll. Esta .dll, junto con la documentación de cómo usarla y algunos ejemplos, puede obtenerse en el sitio de MS:
http://msdn.microsoft.com/vfoxpro/downloads/vfpcom.exe
Esta .dll es un COM Server e incluye una única clase, comutil, que tiene una serie de métodos que proveen dos tipos de funcionalidades bien diferentes, pero que ambos pueden ser de utilidad cuando se trabaja con
ADO.
Por una parte, están los métodos RsToCursor y CursorToRs. Cómo su nombre hace suponer, estos métodos permiten convertir RecordSets de ADO a cursores de VFP y viceversa. Ya existían unas funciones para realizar estas tareas, desarrolladas por Ken Levy y puestas en el dominio público (pueden obtenerse en el sitio de Ken en:
http://www.classx.com), pero estas .dll realizan la conversión en forma mucho más eficiente. Es necesario aclarar que esta .dll no es soportada por MS salvo en lo que hace a su instalación; dada las constantes actualizaciones de ADO, existe alguna probabilidad de que con el tiempo aparezca algún tipo de incompatibilidad. De hecho, nuestra experiencia es que hay ciertos tipos de datos en RecordSets ADO que la .dll no soporta.
De todas maneras, como lo indican las buenas prácticas de programación, sea cual sea el mecanismo que se utilice para hacer esta conversión, deberá estar convenientemente encapsulado y parametrizado para poder, eventualmente, utilizar un método u otro.
El otro grupo de funcionalidades que provee la vfpcom.dll se refiere a la posibilidad de detectar eventos de objetos COM. Esta funcionalidad no está presente en VFP 6 (si bien ya está anunciado que va a formar parte de funcionalidad básica de VFP 7).
Una de las particularidades de ADO, es su capacidad de generar eventos. Esta .dll permite detectar la presencia de esos eventos desde un aplicación VFP. Sin embargo, la utilidad de estos métodos, va mucho más allá del uso de ADO. Permitiría, por ejemplo, hacer una aplicación VFP que utilice MSMQ (Microsoft Messaging Queue Server), y detecte los eventos asociados a las colas de mensajes. O bien una aplicación de automatización de envío y recepción de emails, que responda a eventos de Outlook.
Esta funcionalidad se implemente a través de 3 métodos de la clase comutil, que son:
- ExportEvents
- BindEvents
- UnBindEvents
El método ExportEvents es para ser usado en “tiempo de desarrollo”. Permite exportar la interfaz del objeto COM (es decir, qué eventos genera) a una clase VFP. La clase VFP se genera en un archivo de texto (es decir, la definición está hecha en forma programática - no visual -, con DEFINE CLASS .... ENDDEFINE).
A partir de esa “cáscara”, se puede desarrollar una clase, que tenga los métodos correspondientes para “atender” a los eventos de la clase COM.
En tiempo de ejecución, a través del método BindEvents se realiza la asociación entre el objeto COM y un objeto de dicha clase VFP. Las siguientes líneas de código muestran cómo asociar una clase VFP a un objeto COM, en este caso, de la clase ADODB.Connection:
oUtil = createobject('vfpcom.comutil')
oConn = createobject('ADODB.Connection')
* ADOConnEvents es una clase VFP,
* desarrollada con la ayuda del método ExportEvents
oMonitorADOConn = newobject('ADOConnEvents','MisClases.prg')
oUtil.BindEvents(oConn, oMonitorADOConn)
A partir de ese momento, cuando el objeto Connection (oConn) genere un evento, se invocará el método correspondiente de la clase ADOConnEvents.
¿Para qué usar algo nuevo?
Ahora bien: supongamos que nos tomamos el tiempo de estudiar y entender el modelo de objetos de ADO y el uso de sus propiedades y métodos, y aprendemos a usarlo desde Visual FoxPro. La pregunta que queda por hacernos es: ¿cuáles son las razones para utilizar un mecanismo nuevo ?. Visual FoxPro, a través de los mecanismo de Vistas Remotas y de SQLPassThrough ofrece mecanismos más que suficientes para desarrollar una aplicación robusta y de buen desempeño.
Una primera razón sería la de poder utilizar las características y posibilidades de OLE DB para acceder a una fuente de datos para la cual dispongamos del correspondiente OLE DB Provider, por ejemplo, a Microsoft SQL Server. Características dentro de las cuales se pueden incluir cuestiones de performance o el uso de nuevas funcionalidades, como ser la obtención de Recordsets jerárquicos (o Data Shapes) a través del uso del provider MSDataShape y la instrucción SHAPE, disponibles si utilizamos ADO.
Una segunda razón podría ser, simplemente, el querer utilizar una tecnología más moderna y con más potencial en cuanto a su evolución futura, de manera de prepararse mejor para la próxima generación de herramientas de desarrollo.
Una tercera razón, quizás la de mayor importancia, es si nos encontramos ante la necesidad de desarrollar una función o método de un componente o clase, al cual se debe enviar, o del cual se deba recibir, un conjunto de datos, es decir, una serie de registros del mismo tipo, cuya cantidad pueda ser variable (por ejemplo, las líneas de detalle de un Pedido). Si se trata de una función o método que va a ser utilizada por otro componente también desarrollado en Visual FoxPro, la solución a esta necesidad, podría resolverse mediante el uso de cursores nativos de Fox. Pero si es necesario que dicho componente sea implementado como una clase COM, entonces es que se hace necesario buscar otra alternativa. Existe la posibilidad de utilizar vectores o conjuntos de caracteres concatenados, o hasta la posibilidad de utilizar XML. En todos estos casos, se deberán desarrollar mecanismos de preparación (codificación o armado) y recepción (de-codificación o parseo) de los datos, que inevitablemente resultarán en código extenso y, probablemente, difícil de mantener. La alternativa de utilizar ADO, ofrece un mecanismo simple y elegante para satisfacer este necesidad. Es decir, el intercambio de información entre el componente desarrollado en Visual FoxPro y sus clientes, se implementará a través del envío y recepción de RecorSets ADO.
Conclusiones
Si bien la decisión de qué mecanismos utilizar en cada caso particular, dependerá del tipo de aplicación y de las necesidades de funcionamiento y performance que se definan, así como de la posible evolución de una determinada aplicación, nos parece que, dada las características del uso de ADO en la presente versión de Visual FoxPro, es recomendable utilizarlo solamente en aquellos casos en que encontremos un beneficio real. Como se dijo, los mecanismo nativos disponibles, ofrecen un grado de productividad mayor, a la vez que un resultado en términos de calidad de la aplicación más que suficientes.
También es cierto, como se dijo, que probablemente las próximas versiones de Visual FoxPro, ofrezcan una mayor integración y permitan aprovechar esta tecnología, de una manera más productiva y eficiente.
Referencias
- Libros
- Programming Ado - David Sceppa - Microsoft Press - ISBN: 0735607648
- PROFESIONAL ADO 2.5 Programming – David Sussman, James Conard, Brian Matsik – Wrox Press – ISBN 1-861002-75-0
