VFP y .Net: Lo mejor de ambos mundos

Autor: Claudio Lassala (www.eps-cs.com)
Traducido por: Ana María Bisbé York (amby@telefonica.net)
Para: PortalFox (www.portalfox.com)

(Sesión VFP and Net: The best of both worlds presentada por el autor en la Conferencia DevEssentials Kansas, 2004)

Visual Studio .Net ya no es más el niño pequeño del barrio. Ya han pasado varios años desde que fuera liberada la primera versión beta, y Microsoft comenzara a invertir tiempo liberando por tercera vez el producto. Visual FoxPro (VFP) existe desde algunos años y Microsoft ha anunciado una nueva versión (VFP 9) para fines de este año. Ambas herramientas tienen muy buenas características que pueden hacer mucho más completa nuestra vida como desarrolladores. Entonces, ¿por qué no utilizar las dos, tomando las ventajas de las mejores características de ambas herramientas? Existen características en .Net que pueden beneficiar grandemente a las aplicaciones VFP, en la forma de escribir el código, utilizando clases .Net. Aprender .Net le puede reportar beneficios incluso si no lo va a utilizar. Por otro lado, VFP provee a los desarrolladores de magníficas herramientas que no existen en .Net. Estas características pueden ser de gran ayuda cuando estamos escribiendo código en .Net y buscamos aquellas características que en VFP son muy comunes. Este artículo demostrará cómo puede obtener lo mejor de ambos mundos.

La perspectiva correcta

Muchos desarrolladores que utilizan .Net como herramienta principal seguramente migraron de Visual Basic y Visual C++. La gran mayoría de los actuales desarrolladores en .Net probablemente nunca utilizaron VFP; pero oyeron hablar de el y seguramente ven al VFP como "una herramienta anticuada".

Los desarrolladores en VFP tienden a ser ferozmente leales a VFP y pueden ser recelosos a las nuevas tecnologías de Microsoft, sintiendo, posiblemente, que cada nueva herramienta aísla más a VFP del foco de atención de Microsoft. Yo creo que cada uno de estos grupos pudieran aprender mucho uno de otro.
Yo había desarrollado con Clipper, Visual Basic, FoxPro 2.x, Visual FoxPro desde la versión 3.0, y más recientemente con .NET. Trato de mantener mente abierta a varias herramientas de desarrollo. He tenido tiempo de preguntarme ¿Cuál es la mejor? Y he adquirido experiencia como para prestar más atención a ¿Cuál es la más apropiada? Y ¿Cómo puedo beneficiarme de ésta o de aquella herramienta?

En este artículo trataré de resumir algunas conclusiones a las que he llegado con relación a VFP y .Net. Deseo dejar bien claro, que expresaré mi punto de vista personal, el que pudiera cambiar en el futuro (lo que puede ocurrir ya que vamos adquiriendo nuevas experiencias y conocimientos cada día). Espero que este artículo le ayude a ganar en perspectiva sobre estos dos productos, incluso, si no está de acuerdo con mi opinión.

.Net no es ya algo nuevo.

Algunos desarrolladores VFP, esperaron a ver si .NET sería exitoso o no. Si nos remontamos a inicios de 2004, entonces veremos que las betas públicas de .NET tienen ya cuatro años. Gran cantidad de nuevas características aportadas al producto han sido demostradas en Whidbey (para el año 2005) y Orcas (la versión que vendrá después de Whidbey). .NET será exitoso porque Microsoft lo hará exitoso. Creo que cambiará de nombre .NET; pero la tecnología se va a mantener por bastante tiempo.

Visual FoxPro: Una herramienta madura

Conocida originalmente como FoxPro, un lenguaje de programación procedural compitiendo en el mismo mercado que otros lenguajes de programación xBase, en 1994 cambió de nombre a Visual FoxPro cuando Microsoft liberó la versión 3.0 y le agregó las posibilidades para programación orientada a objeto. Visual FoxPro aportó además, buena migración de las aplicaciones DOS a Windows. Ya que permitió a los desarrolladores mezclar código procedural heredado con código orientado a objeto. Visual FoxPro ofreció a los desarrolladores la posibilidad de tener una curva de aprendizaje suave, y migrar sus aplicaciones lentamente, mientras iban aprendiendo el nuevo paradigma.

Después de transcurrir casi 10 años (desde la versión 3.0), yo diría que el Visual FoxPro es una herramienta de software madura que se puede utilizar para generar aplicaciones profesionales que se integra con las más novedosas tecnología incluyendo COM +, XML, Servicios Web y ¡.NET! Microsoft ha anunciado que están trabajando en una nueva versión de Visual FoxPro (versión 9.0, con nombre Europa) y Microsoft liberará esta versión en la segunda mitad del 2004.

En mi opinión, VFP es mucho más que un "lenguaje de programación". Pienso que es un "entorno de desarrollo" con un motor de informes, una base de datos, un IDE, y lenguaje de programación que incluye comandos nativos y funciones que manipulan los datos de igual forma que un subconjunto de SQL. En mi opinión, VFP tiene algunas características que son más sólidas que .Net, como el proceso de enlace de datos a los controles en una interfaz visual . Algunos podrán rebatir que la implementación del enlace de datos que existe en .Net es más "poderoso"; pero sinceramente yo pienso que, en comparación con VFP, en muy difícil y no está suficientemente maduro como para ser considerada una buena característica de .NET.

Dos herramientas: Diferentes Pros y Contras

Microsoft tiene dos equipos diferentes desarrollando VFP y .NET. Estas dos herramientas no trabajan de igual forma, aunque pienso que los objetivos a alcanzar en muchos conceptos y características puede ser muy similar (o incluso exactamente igual). Otros objetivos para la nueva versión de cada producto pueden ser muy diferentes. Un desarrollador inteligente que sea consciente de las similitudes y diferencias podrá seleccionar la herramienta más adecuada para solucionar un específico problema de negocio.

He notado que los desarrolladores VFP intentan ver cómo solucionan cada problema con código 100 % VFP (o casi todo), y estos desarrolladores terminan utilizando bibliotecas API que exigen grandes cantidades de código y conocimiento específico. En muchos casos, si el desarrollador de VFP buscara sus soluciones ampliando un poco su área, podría utilizar mucho menos código para desarrollar sus soluciones en lugar de escribir pacientemente todo en VFP.

Por ejemplo, supongamos que desea crear un sitio web con imágenes guardadas en una Base de datos (u otro repositorio para tal fin) y desea mostrar las imágenes en páginas con formato diferente. Cuando el usuario hace clic en la imagen, desea mostrar la imagen en su tamaño original. Sin embargo, antes de mostrar la imagen, usted quiere permitirle al usuario escoger la calidad de la imagen seleccionando su velocidad de ancho de banda (bandwidth speed). Desea, además, determinar, quién es el usuario que está pidiendo la imagen, porque para algunos usuarios desea incluir una nota con el copyright para la imagen.

Una solución en VFP incluye el acceso a varias APIs (esto tiende a ser muy complicado), otra solución es emplear un control ActiveX de tercero. No existe una solución con código 100 % VFP.

En .NET, puede crear una solución para este escenario con pocas líneas de código .Net. Será necesario solamente instanciar algunas clases y llamar a algunos métodos.

Por otra parte, puedo imaginar una situación, en la que queremos acceder a una base de datos SQL Server, ejecutar una consulta y enviar los resultados de la consulta a un archivo en un formato Microsoft Excel. En .Net es necesario utilizar varias clases de ADO.NET para conectar con la base de datos y ejecutar la consulta, luego, necesita escribir algún código de automatización para cargar el Excel y poder generar el archivo. (Por tanto, esta solución requiere también que esté instalado Microsoft Excel en el PC). VFP brinda una solución que necesita sólo dos líneas de código y no necesita del Excel. La primera línea de código utiliza una línea de comando que contiene funciones nativas de VFP para conectar a la Base de datos y ejecutar la consulta. La segunda línea exporta los resultados de la consulta a un archivo con formato Excel.

Podría brindar varios ejemplos donde cada entorno se muestra como el más apropiado para solucionar el problema; pero supongo, que ya tiene mi punto de vista.

.Net y sus ventajas para desarrolladores VFP

Muchas clases

VFP tiene 37 clases bases, incluyendo Form, CursorAdapter, XMLAdapter y otras. Estas clases permiten crear pantallas para la aplicación, manipular datos, y manipular documentos XML. Las Fox Foundation clases (FFC) de Visual FoxPro actúan como envoltorios de las APIs y controles ActiveX, haciendo más fácil utilizar, por ejemplo, funciones para Internet o criptografía y abstraerse de este tipo de funcionalidad. Las Foundation clases de VFP permiten al desarrollador concentrase en otras tareas, en lugar de invertir un gran esfuerzo en código a bajo nivel. Por su parte, el framework .Net tiene alrededor de ¡2.500 clases! El desarrollador .NET tiene disponible muchos servicios a través del uso de estas clases. Además, de estas clases ya mencionadas existen clases para manipulación de imágenes, el framework .NET incluye clases que le permitan trabajar con Internet (HTTP, SMTP), Servicios Web, XML, criptografía, crear formularios para aplicaciones Windows y Web, y un amplio rango de otros servicios. Los desarrolladores en VFP pueden utilizar las clases .NET a través de COM.

Los desarrolladores de VFP puede utilizar VFP para crear servicios Web que pueden ser expuestos como componentes COM. Sin embargo, cuando la solución requiere de un servicio Web más robusto, VFP no es suficiente. Se complican las cosas para una solución desde VFP debido a las limitaciones de los componentes COM además de que debe utilizar el SOAP Toolkit (que a su vez es también un conjunto de componentes COM). Debido a estas limitaciones, Microsoft recomienda que los desarrolladores de VFP creen sus servicios a través de sus propios componentes COM; pero deben ser creados en la interfaz .NET para su servicio Web evitando la utilización de los componentes del SOAP ToolKit. Esto le permite hacer cualquier ajuste o agregar extensiones en .NET. Por ejemplo, es mucho más sencillo aplicar criptografía o cualquier otro tipo de manipulación en la cabecera de una envoltura SOAP (SOAP es un protocolo que hace posible crear mensajes, mandarlos y recibirlos a través de Servicios Web) en .NET más que en VFP (donde debe utilizar filtros ISAPI o ASP tradicional)

Aprender de la tecnología y aplicarla a VFP

.Net ofrece soluciones muy convincentes para escenarios frecuentes en el mundo actual del desarrollo de aplicaciones. Por ejemplo, ASP.NET permite a los desarrolladores crear aplicaciones Web utilizando la metáfora similar a la utilizada para crear aplicaciones Windows, basadas en orientación a objetos y eventos. En otras palabras, un desarrollador no necesitará utilizar puro código HTML para crear controles comunes de formularios (textbox, combobox, listbox, grid, etc), y luego utilizar JavaScript para ejecutar código que dispara eventos específicos a través del Web browser. ASP.NET ofrece clases especializadas que permiten a los desarrolladores .NET crear controles basados en objetos reales para sus páginas web.

Inspirado en la tecnología introducida por ASP.NET, Markus Egger, Chief Software Architect en EPS Software Corp., creó hace algunos años (cuando .NET estaba todavía en la primera versión beta) los Controles Voodoo Web. Este es un producto, que consiste en varias clases escritas en VFP que imita en cierta medida al mecanismo del ASP.NET, y que proporciona al desarrollador de VFP una mayor productividad y vía robusta para la creación de aplicaciones Web.

Cuando Microsoft lanzó el .NET, introdujo el control estructurado de errores (structured exception handing) (incluyendo el popular bloque try/catch) en sus lenguajes, permitiendo a los desarrolladores mantener encapsulamiento en sus clases (lo cual es muy bueno). Al mismo tiempo, VFP (en su versión 7.0) no tenía una forma análoga para el tratamiento de excepciones. Terminé aprendiendo de excepciones estructuradas manipulando y ajustando su utilización. Luego, Visual FoxPro 8.0 brindó esta magnífica característica y fue una de las cosas en las que invertí menos horas estudiando. Pienso, que es importante tener en cuenta, que, aunque son dos equipos diferentes dentro del trabajo de Microsoft que desarrollan VFP y .NET, estos equipos intercambian información entre ellos y espero que continúe viendo nuevas características de .NET en VFP y viceversa.

Adopción de "Buenas prácticas"

Los desarrolladores VFP pueden verse beneficiados de los conceptos y normas que, en la mayoría de los casos, exige .Net. Por ejemplo, los desarrolladores VFP pueden ser "perezosos" ya que VFP les permite no escribir strong-typing De hecho, no existe en VFP verdadera escritura strong-typed (las versiones VFP 7.0 y posterior, permuten definir tipos; pero sólo son utilizadas para soportar IntelliSense y para soportar bibliotecas tipo COM) El desarrollador VFP no tiene que declarar el tipo de la variable o el tipo de la propiedad, tampoco tiene que declarar el tipo de parámetros o el tipo en que devuelve el método). Absolutamente todo en VFP está en los tipos de variables, y esto significa que un código puede asignar cualquier tipo de valor u objeto a cualquier variable. A pesar de la flexibilidad que brinda esto al desarrollo en VFP, se convierte en un precio muy alto. Es muy fácil para los desarrolladores en VFP escribir código que contengas errores, y frecuentemente estos errores son difíciles de encontrar.

En .Net, los lenguajes son de tipo estricto lo que fuerza a los desarrolladores a declarar variables y sus tipos. Cualquier intento de asignar valores a una variable que no ha sido declarada con el tipo correspondiente, provoca que el código no se pueda compilar. Esto provoca gran número de errores que sólo se detectan en VFP en tiempo de ejecución, sean solucionados en .NET en tiempo de diseño. En caso de que piense que necesita ese tipo de flexibilidad, .NET tiene mecanismos que permiten a los desarrolladores escribir código flexible; pero sólido.

Pienso además, que VFP es demasiado complaciente en cómo utiliza la herencia. Es muy fácil sobrescribir un método en una clase por error. Piense esta situación: Ha definido una clase SerHumano que tiene un método Hablar en la clase Hombre. Suponga que no sabe que el método Hablar ya existe en la clase base y que no utiliza la función DoDefault() para llamar al código heredado. ¿Adivinen? Se rompe la herencia. En dependencia de la complejidad del modelo de clases en su aplicación, varía cuán difícil puede resultar detectar este problema.

En .NET no puede crear este tipo de problemas accidentalmente, porque el compilador alertará al desarrollador acerca de cualquier intento de sobrescribir miembros heredados de una clase base. Además, .NET soporta la creación de métodos o clases abstractas (las que pueden ser implementados por sus subclases, y en el caso de las clases, nunca serán instanciados), y clases selladas, aquellas que no pueden ser subclaseadas.

El tiempo dirá

Desde que comencé a escribir código .NET, presto más atención a este tipo de detalles cuando escribo código VFP. Como resultado, el código VFP tiene mayor calidad. Esencialmente, .NET me ha enseñado a desarrollar código sólido de forma natural, y ahora yo no provoco en mi código VFP, muchas de las situaciones que desafortunadamente, el compilador de VFP no puede detectar.

Algunas ventajas de conocer Visual FoxPro cuando se utiliza .Net

Programación orientada a objeto

El desarrollador de VFP podrá reutilizar gran cantidad de conocimiento al escribir código .Net. Como he dicho antes, VFP implementó hace muchos años programación orientada a objeto. En .NET , todo es un objeto. Debido a que los desarrolladores en VFP están acostumbrados a este modelo de programación, tienen un gran trecho adelantado en .NET en comparación con los desarrolladores que provienen de Visual Basic 6.0, los que no tienen una implementación real de orientación a objetos.

Recuerdo que en el año 2002, yo estaba presentando un seminario de entrenamiento titulado "Programación orientada a objeto en Visual FoxPro" en las dependencias de Microsoft, en Sao Paulo. Poco más de la tercera parte de los asistentes eran desarrolladores VB ansiosos de aprender algo sobre programación orientada a objetos, incluso a través de mi presentación, que fue en VFP. Al final de mi presentación, los desarrolladores VB aprendieron lo fundamental, porque al fin habían entendido el paradigma de POO.

La forma en que lo hacen en VFP

VFP brinda funcionalidad integrada que requiere muchas líneas de código duplicarlas en .NET. Suponga, por ejemplo, que como parte de una aplicación tenemos la cadena ("este es un texto") y quiere conocer cuántas ocurrencias tiene la letra "s" en la cadena. En VFP utilizaría la función Occurs. .NET no contiene esta función, tal como la necesita, y toca escribir un código de aproximadamente una docena de líneas. Un desarrollador experimentado en VFP tiene ventaja en productividad. A la aplicación que está creando no le interesa si utiliza VFP o .NET una vez que puede solucionar el problema.

Para ayudar al desarrollador VFP en su tránsito a .Net, Microsoft ha liberado: "Visual FoxPro Toolkit for .NET" (localizado en http://www.gotdotnet.com/team/vfp). Esta librería de clases contiene 255 funciones escritas en .Net que imitan funciones creadas en VFP. Estas herramientas son muy convenientes por las siguientes razones:

1. Facilita la migración de código VFP a .Net
2. Viene con todo el código fuente y ayuda (para VB.NET y C#). Puede aprender como trabaja .Net analizando el código fuente y la ayuda.

El toolkit no substituye el tener que aprender el framework .NET y un lenguaje .NET (es decir VB.NET o C#). Es importante enfatizar que incluso pensando que el toolkit puede ayudar, los desarrolladores VFP tienen que aprender a escribir el código en .NET, que puede ser muy similar a cómo escriben código en VFP, los desarrolladores VFP deben utilizar el toolkit solamente cuando se ponen en primer contacto con .NET, tan pronto pasen ese estado inicial, deben aprender a escribir código .NET en la forma en que lo hace .NET. Por ejemplo, VFP hace concatenación de cadenas en un lazo, agregando cadenas a una variable. En .NET, incluso pensando que logrará la tarea de la misma manera, la mejor opción es utilizar la clase StringBuilder de .NET que tiene mejor rendimiento que la concatenación en un lazo. (De hecho, StringBuilder es más rápido que VFP, que es siempre rápido en este tipo de operaciones).

¿Estará VFP dentro de .Net?

Muchos desarrolladores han preguntado si existirá VFP.NET (en otras palabras, si se convertirá VFP en un lenguaje .NET) Hasta el momento de escribir este artículo la respuesta de Microsoft es no.

Microsoft tiene muchas razones técnicas para esta respuesta, pero para hacer la historia corta, voy a resumirla de esta forma: Para que VFP sea lenguaje .Net tiene que poderse ejecutar por el CLR (runtime .NET). Para ello, VFP perdería muchas de las características que lo distinguen de otros lenguajes .NET, (macro expansión, convertirse en lenguaje de tipo estricto, eliminar comandos nativos para manipulación de datos, generador de informes, etc). Esto puede entenderse como echar a la basura todas las aplicaciones existentes escritas en versiones anteriores de esta herramienta, olvidarse de la compatibilidad hacia atrás lo que es una característica esencial para cada nueva versión de un lenguaje de programación.

Si tiene curiosidad, puede encontrar detalles técnicos de lo que podría ocurrir con VFP para convertirlo en lenguaje .NET en Internet, principalmente en el foro de VFP en Universal Thread (www.universalthread.com).

Conclusión

Sin importar cuánto yo haya escuchado sobre el futuro de .NET, de algo estoy seguro, .NET no va a desaparecer pronto. Incluso si Microsoft renombra .NET, la tecnología introducida en esta plataforma va a continuar evolucionando y los desarrolladores experimentados en .NET podrán adaptarse a los cambios de este entorno de desarrollo.

Los desarrolladores que decidan continuar utilizando VFP como su herramienta principal para el desarrollo de aplicaciones deben tener la mente abierta con las cosas que van ocurriendo a su alrededor. Esta misma línea se aplica a pensar cómo sus aplicaciones pueden coexistir lo mejor posible con desarrollos .Net

Claudio Lassala (classala@eps-software.com) es Senior Developer en EPS Software Corporation localizada en Houston, TX, y consultante en Universal Thread. Ha realizado varias presentaciones en Microsoft Brazil y conferencias VFP / .NET en Brazil y América del Norte. Ha ganado el premio Microsoft MVP desde 2001, Es Microsoft Certified Application Developer (MCAD) para plataforma .NET y un Desarrollador Cinco Estrellas (Five Stars Developer) en MSDN Brazil. Es columnista para MSDN Brazil y escribe regularmente para varias revistas especializadas incluidas FoxPro Advisor y Universal Thread Magazine. Es autor de varios videos de entrenamiento para Visual FoxPro disponibles en Universal Thread.