Clique aqui para ler todos os artigos desta edição
.NET e VFP juntos: faz sentido?
por Claudio Lassala
A esta altura, o .NET não é mais nenhuma novidade. Vários anos se passaram desde o lançamento da primeira versão beta. O Visual FoxPro (VFP) também está aí há muitos anos e uma nova versão já está sendo produzida. Ambos têm ótimas características, que podem tornar nossas vidas de desenvolvedores muito mais completas. Então, por que não usar as duas ferramentas, aproveitando o melhor de cada uma para cada tarefa? Existem funcionalidades no .NET que são de grande benefício para nossas aplicações VFP. Da forma como você escreve seu código até a utilização de classes .NET em suas aplicações VFP, aprender o.NET lhe trará benefícios mesmo que você não esteja planejando utilizá-lo de forma exclusiva. Por outro lado, como o VFP é um produto muito maduro, ele nos oferece grandes funcionalidades, não disponíveis no .NET. Essas funcionalidades poderão ser muito úteis quando você estiver escrevendo código em .NET e buscar funcionalidades comuns ao mundo do VFP. Este artigo aborda exatamente como ter o melhor de ambos os mundos na ponta dos dedos.
Um breve histórico
A discussão sobre qual é a melhor linguagem de programação não é nova, e parece estar longe de chegar ao fim. No mundo do desenvolvimento de software, a figura da “linguagem de programação” tem dado cada vez mais lugar à figura do “ambiente de desenvolvimento”. Neste cenário, tanto o Visual FoxPro (VFP) como a plataforma .NET podem exercer diversos papéis importantes no desenvolvimento de software, os quais transcendem a simples “linguagem de programação”.
Grande parte dos desenvolvedores que fazem do .NET sua principal ferramenta certamente migraram de plataformas como o VB 6 e VC++. A imensa maioria deles vê o VFP como “uma ferramenta ultrapassada”, geralmente porque o amigo do amigo ouviu algum comentário desse tipo, mas na verdade eles nunca se deram ao trabalho de conhecer mais detalhes sobre o produto.
Por outro lado, os desenvolvedores VFP geralmente defendem com unhas e dentes sua principal ferramenta de trabalho e acabam por desenvolver um sentimento negativo de aversão a qualquer nova tecnologia que seja criada pela Microsoft. Como a plataforma .NET é a mais recente tecnologia para desenvolvimento criada pela Microsoft, este se tornou o principal alvo da ira desses desenvolvedores. Em última instância, essas pessoas acabam cometendo o mesmo pecado do pessoal do .NET: não conhecem aquilo que está do outro lado do muro e nunca chegam a ter contato com a ferramenta para tentar descobrir o que ela pode oferecer em seu benefício.
Tendo trabalhado com o Clipper, VB 3, FoxPro 2.x e Visual FoxPro (desde sua versão 3.0 até a última, 8.0) e, mais recentemente, com o .NET, procuro sempre manter a mente aberta às novidades que aparecem e desaparecem com o tempo. Isso me permitiu abstrair a questão do “qual é a melhor?” e passei então a refletir sobre “qual é a mais adequada?” ou, então, “o que posso tirar de bom desta ou daquela tecnologia?”
O .NET já não é mais novidade
Muitos desenvolvedores VFP continuam a ver o .NET como uma novidade cujo futuro ainda é incerto. Deve-se lembrar que, aproximadamente dois anos antes de seu lançamento oficial, em fevereiro de 2002, as versões betas do .NET já eram utilizadas por um imenso número de pessoas. Se somarmos esse tempo aos quase dois anos pós-lançamento, já podemos considerar quatro anos de tecnologia.
Em 2003, foi lançada uma nova versão do .NET framework e do Visual Studio .NET, chamada Visual Studio .NET 2003, cuja próxima versão (codinome Whidbey) vem sendo testada há vários meses em versão beta. O Whidbey foi planejado para ser lançado em 2004, mas, mesmo assim, a Microsoft já trabalha em seu sucessor, codinome Orca. Ou seja, mesmo que daqui a alguns anos o .NET passe a ter qualquer outro nome, a tecnologia em si estará aí madura para ser usada. Vale lembrar que o .NET foi originalmente destinado a ser uma nova versão do COM+ e, ao final, passou a ser chamado .NET.
Visual FoxPro: uma ferramenta madura
Após vários anos conhecido como FoxPro (uma linguagem de programação procedural que competia no mercado das linguagens xBase), em 1994 este produto passou a se chamar Visual FoxPro (VFP), quando foi lançada a versão 3.0, que trazia como grande diferencial o suporte à Programação Orientada a Objetos. Valendo-se também da capacidade de mesclar o código procedural legado de suas aplicações existentes com o código orientado a objetos, o desenvolvedor teve a chance de amenizar a curva de aprendizado, migrando suas aplicações em um ritmo mais suave e desenvolvendo suas classes de objetos enquanto aprendia esse novo paradigma.
Após a versão 3.0, foram lançadas as versões 5.0, 6.0, 7.0 e, mais recentemente, a versão 8.0. Após quase dez anos (desde a versão 3.0), pode-se dizer que esta é uma ferramenta bastante madura, com a qual podemos criar aplicações profissionais e integrar essas aplicações a ferramentas e tecnologias como COM+, XML, Web Services e, adivinhe, .NET!
Além disso, uma nova versão (a 9.0, codinome Europa) já se encontra em estágio avançado de desenvolvimento, a ser lançada no segundo semestre de 2004.
Não há dúvidas que o VFP deixou a muito tempo de ser uma simples linguagem de programação e se tornou um ambiente de desenvolvimento, com gerador e visualizador de relatórios, banco de dados, IDE e a linguagem de programação, que por sua vez possui linguagem nativa para acesso a dados, linguagem SQL, etc. Por conta disso, fica claro que em algumas áreas esse produto pode ser considerado mais sólido que o .NET como, por exemplo, no data-binding (vinculação de dados a controles na interface visual das aplicações). Apesar de aparentemente esta ser uma área mais poderosa no .NET, ela ainda não está madura o suficiente para ser considerada uma grande característica do ambiente.
Dois ambientes: diferentes qualidades e defeitos
Obviamente, ambos os ambientes possuem qualidades e defeitos (aliás, como tudo nesta vida). No caso do .NET e VFP, existem diferentes equipes de desenvolvimento na Microsoft trabalhando no aprimoramento desses produtos. Desse modo, não podemos esperar que eles operem de forma exatamente igual. Apesar de alguns conceitos e características serem bastante similares (e às vezes até iguais), pode haver algumas coisas realmente diferentes (ou inexistentes) entre um produto e outro. Estar ciente dessas diferenças permite ao desenvolvedor escolher a ferramenta adequada para a implementação de cenários específicos.
Por exemplo, desenvolvedores VFP sempre buscam resolver problemas com soluções 100% VFP (ou quase) e terminam utilizando bibliotecas API ou outras soluções que demandam um volume maior de código ou conhecimento específico. Se eles ampliassem seus horizontes, passariam a buscar a melhor ferramenta para desenvolver a solução, no lugar de tentarem duramente escrever tudo em VFP.
Tome como exemplo a manipulação de imagens programaticamente. Imagine um website onde as imagens sejam armazenadas em um banco de dados (ou qualquer que seja o repositório) e apresentadas em páginas de diferentes formatos. Suponha que na primeira página sejam apresentadas apenas as miniaturas (thumbnails) das fotos e, quando o usuário clicar na foto, apresentamos a foto em tamanho original. Primeiramente, damos ao usuário a opção de escolher a qualidade da foto, pois dependendo da velocidade da conexão com a Internet de que dispõe, ele poderá escolher uma qualidade alta ou baixa. Além disso tudo, também queremos controlar a exibição do copyright em todas as fotos, dependendo de quem é o usuário que solicita a foto.
Pense bem: isso não é nada de que um website não necessite hoje em dia. Como implementar isso em VFP? Uma maneira seria acessar funções diversas em APIs específicas, geralmente bastante complicadas. Outra forma seria adquirir controles ActiveX de terceiros e fazer uso deles. Não existe nenhuma solução 100% VFP.
No .NET, todo esse cenário é implementado com poucas linhas de código, sem necessidade de utilizar qualquer ActiveX de terceiros nem manipular APIs diretamente. Tudo isso está pronto para o uso através de classes, e só o que precisamos fazer é instanciar classes e invocar métodos.
Por outro lado, posso imaginar uma situação em que precisemos acessar um banco de dados SQL Server, executar alguma consulta e gerar um arquivo no formato MS-Excel com o resultado da consulta. No .NET, seria necessário utilizar diversas classes do ADO.NET para fazer a conexão com o banco de dados e executar a consulta e, então, executar algum tipo de automação (o que requer a existência do MS-Excel instalado no computador) para gerar o arquivo. Aqui é a vez do VFP apresentar uma solução muito melhor: todo o cenário é implementado com apenas 2 linhas de comando, sem necessidade de ter o MS-Excel instalado no computador e sem necessidade de APIs como o ADO. Basicamente, em uma linha de comando, com funções nativas do VFP, fazemos a conexão com o banco de dados e a execução da consulta e, na segunda linha, exportamos o resultado da consulta para um arquivo em formato MS-Excel.
É possível delinear uma série de exemplos onde cada ambiente revele-se a solução mais apropriada para cada cenário, mas imagino que você já tenha compreendido a idéia.
O .NET e seus benefícios para desenvolvedores VFP
Diversas classes prontas para uso
Na sessão anterior, mencionei um simples exemplo no qual desenvolvedor VFP pode beneficiar-se do .NET. Nesta sessão, procurarei delinear mais alguns exemplos.
O VFP 8.0 tem cerca de 37 classes-base (como Form, CursorAdapter, XMLAdapter, etc.). Essas classes permitem ao desenvolvedor criar telas para as aplicações, manipular dados e manipular documentos XML, dentre algumas outras funcionalidades. Além disso, traz também algumas “Foundation Classes” (Fox Foundation Classes), que funcionam como wrappers de APIs ou controles ActiveX, facilitando a manipulação de funções de Internet, Criptografia, etc. e abstraindo esse tipo de funcionalidade para que o desenvolvedor possa se concentrar em outras tarefas, em vez de investir tempo em funções de baixo nível. O .NET framework, por outro lado, tem cerca de 2.500 classes. Dá para você imaginar o número de serviços disponíveis para o desenvolvedor através dessas classes? Assim, além das classes para manipulação de imagens, estão disponíveis classes para trabalho com a Internet (HTTP, SMTP), Web Services, XML, Criptografia e criação de telas, tanto para aplicações Windows como para aplicações Web, e esta lista abrange diversos outros serviços. Essas classes podem ser expostas para o VFP através do COM.
Os Web Services são um bom exemplo. Podemos criar Web Services em VFP para serem expostos através de componentes COM. É relativamente fácil criar Web Services simples, mas quando precisamos de soluções mais flexíveis e poderosas, as coisas tornam-se realmente complicadas, pois ficamos limitados à natureza da tipagem-fraca do VFP e às limitações do COM, além de à utilização do SOAP Toolkit (que, por sua vez, também é um conjunto de componentes COM). Por esses motivos, a própria Microsoft recomenda que os desenvolvedores VFP criem seus serviços através de componentes COM mas desenvolvam a interface para esses componentes através de um Web Service criado em .NET, dispensando assim a utilização do SOAP Toolkit e aproveitando os benefícios do .NET. Desse modo, é possível implementar qualquer refinamento ou extensão necessária em .NET. Por exemplo, é muito mais fácil aplicar criptografia ou efetuar qualquer outro tipo de manipulação no cabeçalho (header) de um envelope SOAP (protocolo que possibilita a criação de mensagens enviadas e recebidas pelos Web Services) em .NET do que fazer o mesmo em VFP (onde seriam necessários filtros ISAPI ou, então, a utilização do ASP tradicional).
Aprendizado de tecnologia e aplicação no VFP
O .NET traz diversas soluções para diferentes cenários freqüentes no mundo atual do desenvolvimento de software. As aplicações para Web são um exemplo disto. Através do ASP.NET, os desenvolvedores podem criar aplicações para Web utilizando uma metáfora similar a utilizada em aplicações Windows, baseada na orientação a objetos e eventos. Ou seja, em vez de escrever puramente código HTML para criar os controles típicos em uma tela (textbox, combobox, listbox, grid, etc.) e utilizar JavaScript para executar códigos em função de determinados eventos disparados pelo usuário por meio do navegador Web, o ASP.NET disponibiliza uma série de classes especializadas para que criemos controles baseados em objetos reais para nossas páginas Web.
Inspirado nessa tecnologia introduzida pelo ASP.NET, Markus Egger, Chief Software Architect da EPS Software Corp., criou anos atrás (quando o .NET ainda estava em suas primeiras versões beta) o Voodoo Web Controls. Este produto consiste em uma série de classes escritas puramente em VFP e que imitam de certa maneira a maneira como o ASP.NET trabalha. Com isso, ele fornece ao desenvolvedor VFP uma forma muito mais produtiva e robusta para desenvolver aplicações Web.
O meu argumento aqui é que, conhecendo tecnologias introduzidas no .NET para a solução de cenários típicos, podemos de alguma forma procurar criar algo semelhante para resolver aos mesmos cenários em VFP.
Outro fato: quando lançado, o .NET trouxe em suas linguagens o tratamento estruturado de exceções (os famosos blocos try/catch), os quais, como o nome sugere, permite-nos tratar de forma estruturada erros e exceções que venham a ocorrer em nosso código. Naquela época, o VFP (então em sua versão 7.0) não possuía recursos para tratamento de exceções e, a princípio, estranhei tudo aquilo, mas finalmente aprendi a usá-los e me acostumei. Meses depois, quando o VFP 8.0 foi lançado, trouxe consigo também os blocos try/catch. Conclusão: foi uma coisa a menos que precisei aprender nesta nova versão do VFP, e ganhei muitas horas de economia.
É muito importante enfatizar o fato de que, apesar de existirem duas equipes diferentes dentro da Microsoft trabalhando e desenvolvendo o VFP e o .NET, essas equipes trocam informações entre si, o que significa que veremos cada vez mais características do .NET dentro do VFP e vice-versa.
Adoção de boas práticas
Além desses benefícios (utilização de serviços disponíveis nativamente no .NET), os desenvolvedores VFP podem se beneficiar de conceitos e boas práticas que são praticamente obrigatórios em .NET. Por exemplo, o desenvolvedor VFP acaba ficando “preguiçoso” com a benevolência do VFP no que se refere à tipagem-forte. A tipagem-forte na verdade nem existe no VFP (podemos definir “tipos” a partir do VFP 7.0, mas isso é feito apenas para suportar o mecanismo do IntelliSense e também para auxiliar na criação de Bibliotecas de Tipo para componentes COM). Isso significa que o desenvolvedor não precisa declarar tipos de variáveis, tipos de parâmetros, retorno de métodos nem tipos de propriedades. No VFP, absolutamente tudo é variante, e assim sendo, qualquer tipo de valor ou objeto pode ser atribuído a qualquer variável. Apesar da flexibilidade que essa característica proporciona, o preço a ser pago por ela é muito alto: escrevemos código com uma propensão a bugs muito alta e, geralmente, esses bugs são de muito difícil depuração.
No .NET, as linguagens têm tipagem-forte, o que significa que somos obrigados a declarar variáveis e seus tipos, e qualquer tentativa de atribuir um valor a uma variável onde os tipos sejam diferentes irá gerar um erro na compilação. Em troca da flexibilidade na ponta dos dedos, ganhamos o compilador, que nos permite detectar bugs imediatamente. Caso o leitor esteja se perguntando “Mas e se eu precisar daquela flexibilidade em algum cenário?”, a resposta é: existem diversos mecanismos para criar código flexível sem comprometer a escrita de código mais sólido.
Outra situação na qual o VFP é muito condescendente com erros se dá no caso da herança. É muito fácil sobrescrever um método em uma classe sem que haja intenção de fazê-lo. Imagine esta situação: temos uma classe SerHumano definida em uma biblioteca. Esta classe tem um método Falar. Surge a necessidade de definirmos a classe Homem, que herda da classe SerHumano. O desenvolvedor decide definir um método Falar na classe Homem e, por não saber da existência do mesmo método na classe-base, não utiliza a função DoDefault() para invocar o código herdado. Adivinhe o que acontece? A herança é quebrada e, dependendo da complexidade do modelo de classes de uma aplicação, fica muito difícil detectar esse problema.
No .NET, este problema não ocorre de maneira acidental, pois o compilador alertará ao desenvolvedor sobre tentativas de sobrescrever membros herdados de uma classe-base. Além disso, temos suporte sintático para definirmos classes ou métodos abstratos (aqueles que deverão ser implementados pelas subclasses e, no caso de classes, jamais poderão ser instanciadas), classes seladas (aquelas que não podem ser subclassificadas), etc.
Após algum tempo escrevendo código em .NET, fatalmente acabaremos prestando mais atenção a esses detalhes quando estivermos escrevendo código em VFP e, com isto, nosso código em VFP será de muito melhor qualidade. Por exemplo, ao solicitar uma variável, ela deverá ser sempre declarada (caso já não o tenha feito) e ter seu tipo definido. Ou, então, quando estiver criando subclasses, fique atento aos membros já definidos na classe-base. Essencialmente, escreva código sólido mais naturalmente e deixe de se preocupar com problemas no código que o compilador do VFP infelizmente não poderia detectar.
Benefícios de conhecer VFP quando estamos no .NET
Programação Orientada a Objetos
O desenvolvedor VFP não deve supor que seu conhecimento não servirá para nada quando estiver escrevendo código em .NET. Muito pelo contrário. Como já mencionei, há dez anos o VFP implementa programação orientada a objetos. No .NET, tudo é objeto. Assim, se o desenvolvedor VFP estiver familiarizado com este modelo de programação, já estará inúmeros passos à frente no aprendizado do .NET, se comparado com um desenvolvedor vindo do Visual Basic 6.0, por exemplo, que não possuía uma implementação real de orientação a objetos.
Ainda me lembro quando, no início de 2002, apresentei duas vezes a palestra “Programação Orientada a Objetos com o Visual FoxPro” no auditório da Microsoft em São Paulo. Mais de 1/3 das pessoas presentes naquela ocasião eram desenvolvedores VB, ansiosos por aprender alguma coisa sobre Programação Orientada a Objetos, mesmo se tratando de apresentação baseada no rival VFP. Posso dizer que, ao final da palestra, os aplausos mais fortes vieram dessas pessoas, que finalmente conseguiram entender de uma vez por todas o que estava por trás desse paradigma. Como estavam prestes a migrar para o VB.NET, elas precisavam a qualquer custo familiarizar-se com estes conceitos, até então totalmente novos.
Como fazemos no VFP
Outra situação real é que existem algumas funcionalidades que requerem várias linhas de código para serem implementadas em .NET. Por exemplo, no VFP, quando temos uma string (por exemplo “isto é um teste”) e desejamos obter uma contagem de quantas ocorrências da letra “s” temos nesta string, simplesmente utilizamos a função Occurs(). No .NET, não existe uma função como esta, e é necessário escrevê-la com quase uma dúzia de linhas de código. O fato é que, por conhecermos a função Occurs do VFP, simplesmente não queremos ficar criando funções em .NET para fazer algo que nossa “velha raposa” já fazia há anos.
A boa notícia é que foi criada uma ferramenta gratuita chamada “VFP Toolkit for .NET” (encontrada em http://www.gotdotnet.com/team/vfp/). Trata-se de uma biblioteca de classes escrita em .NET que possui funções similares às 255 funções existentes no VFP. Assim, temos ao nosso dispor no .NET as principais funções do VFP, como funções de manipulação de Strings (StrToFile, FileToStr, Occurs, At, etc.), funções matemáticas, funções para manipulação de dados, etc. Esta ferramenta é útil pelas seguintes razões:
1. Facilita a migração de código VFP para código .NET por meio de funções do toolkit que imitam funções do VFP;
2. Todo o código-fonte e help são disponibilizados (com código tanto em VB.NET como C#). Com isto, é possível aprender como algumas coisas devem ser feitas em .NET analisando-se o código das funções.
É importante frisar o seguinte: apesar de essas opções propiciarem uma maneira de escrevermos código em .NET de forma semelhante à escrita em VFP, só deveremos usá-las quando estivermos dando nossos primeiros passos no mundo do .NET; assim que passarmos desta fase, devemos aprender a escrever o código em .NET de forma apropriada. Por exemplo, no VFP, fazemos as concatenações de string em um loop, adicionando strings a uma variável. No .NET, apesar de também ser possível fazer desta forma, a melhor opção é utilizar uma classe chamada StringBuilder, que apresenta uma performance muito superior ao método tradicional (inclusive mais rápido do que o VFP, que sempre foi muito rápido neste tipo de operação).
Existirá um VFP .NET?
Existirá um VFP .NET (em outras palavras, será o VFP uma linguagem .NET?)? Esta pergunta é feita milhares de vezes, e até o momento em que este artigo foi escrito, a resposta da Microsoft era não.
Existem razões técnicas para isso e, para encurtar uma longa história, vou resumir assim: para ser uma linguagem .NET, o VFP precisaria ser executado pelo CLR (runtime do .NET). Para isto, ele precisaria perder todas as características que o diferenciam das demais linguagens .NET (como a macroexpansão, passar a ser uma linguagem de tipagem-forte, extinguir os comandos nativos para acesso e manipulação de dados, etc.). Essa mudança significaria jogar pelo ralo todas as aplicações existentes escritas em versões anteriores da ferramenta, ou seja, desprezar a compatibilidade retroativa que sempre foi uma característica forte do VFP a cada nova versão da linguagem.
Muitos detalhes técnicos sobre o que seria necessário para tornar o VFP uma linguagem .NET podem ser encontrados na Internet, principalmente no fórum de VFP, no Universal Thread (www.universalthread.com).
Conclusão
Por mais controverso que seja o futuro do .NET, é impossível afirmar que ele seja uma moda passageira que perecerá em breve. Como mencionei neste artigo, mesmo que em alguns anos o .NET não exista com esse nome, a tecnologia introduzida por esta plataforma estará aí, e quem estiver confortável com ela desde agora não terá problema nenhum para acostumar-se com quaisquer alterações que porventura a plataforma venha a sofrer, pois a raiz já estará plantada.
Como procurei enfatizar em diversos momentos, o fato de o desenvolvedor desejar continuar utilizando o VFP como sua principal ferramenta de trabalho não significa que ele não deva manter a mente aberta para as coisas que estão acontecendo ao seu redor no fantástico mundo do desenvolvimento de software. Este mesmo raciocínio vale para os desenvolvedores .NET.
