msdn05_capa.JPG

Clique aqui para ler todos os artigos desta edição

 

.NET para Desenvolvedores VFP

por Claudio Lassala

Após ler meu artigo publicado na edição de fevereiro da MSDN Magazine Brasil, o desenvolvedor em Visual FoxPro talvez tenha se animado a dar alguns passos no mundo .NET. Neste artigo, apresentarei uma visão geral do .NET sob o ponto de vista de um desenvolvedor VFP, de modo a fornecer um ponto de partida para aqueles que estão se iniciando nessa tecnologia.

 

O Ambiente Integrado de Desenvolvimento

 

Como ninguém em sã consciência gosta de escrever programas no Notepad e, depois, compilá-los diretamente no prompt de comando do MS-DOS, felizmente tanto o VFP como o .NET dispõem de ambientes integrados de desenvolvimento (ou IDE, de “Integrated Development Environment”). A IDE mais comum para o .NET é o Visual Studio.NET (ou VS.NET), com a qual se pode criar aplicações para Windows, Web, dispositivos móveis, etc. Alternativamente, para o desenvolvimento Web existe também uma ferramenta gratuita chamada Web Matrix.

O VS.NET tem diversas similaridades com a IDE do VFP, como mostra a Figura 1. Alguns exemplos:

 

·         Caixa de Ferramentas (Toolbox): bastante parecidas em ambos os ambientes, possuem o mesmo tipo de funcionamento, com ícones dispostos em “tabs” diferentes, de forma a agrupar objetos de acordo com a necessidade do usuário. Em termos de customização, o VFP 8.0 trouxe uma caixa de ferramentas ainda melhor, que pode ser customizada de diferentes maneiras não permitidas no VS.NET, como, por exemplo, a possibilidade de criar um grupo baseado em uma biblioteca de classes ou um grupo que traz arquivos contidos em um determinado diretório.

·         Lista de Tarefas (Task List): os dois ambientes possuem uma lista de tarefas onde o desenvolvedor pode adicionar itens “a fazer” (to do) ou qualquer outro item que ele deseje listar como lembrete.

·         Janela de Propriedades (Properties Window): o funcionamento básico em ambos os ambientes é muito parecido. É possível atribuir ou alterar valores de propriedades de objetos selecionados. A principal diferença é que a organização da janela de propriedades no VS.NET é um pouco diferente e não permite acesso a métodos. Os métodos no VS.NET são acessados através de ComboBoxes, no topo do editor de código (similar ao editor de código do Visual Class Designer do VFP). Uma característica importante no VS.NET (inexistente no VFP) é a possibilidade de determinar como a janela de propriedades deve se comportar para cada classe específica, através de atributos aplicados na definição da classe. Não entrarei em detalhes, mas, por exemplo, imagine uma classe “Carro” que possua uma propriedade “Cor”. É possível aplicar atributos para essa propriedade de modo que, ao selecioná-la na janela de propriedades, você tenha a opção de selecionar a cor através da caixa padrão de seleção de cores do VS.NET. Esse procedimento não é possível no VFP.

·         Ajuda (Help): a Ajuda do VS.NET pode ser mostrada exatamente como no VFP, ou seja, em uma janela individual. Entretanto, a Ajuda também está integrada na IDE, o que significa que não é preciso deixar o ambiente de desenvolvimento para conseguir ajuda sobre algo. Por exemplo, com o recurso de ajuda dinâmica (dynamic help), quando você digita alguma palavra-chave na edição de código, é exibida imediatamente uma lista de Ajuda, facilitando o acesso às definições de comandos, sintaxe, exemplos, e tudo que estiver disponível sob aquele contexto.

·         Navegador de Objetos (Class Browser) e Navegador de Classes (Class Browser): ambos os recursos estão presentes no VS.NET e, apesar de possuírem características um pouco diferentes, possuem funcionamento similar, portanto, o desenvolvedor VFP não deverá ter dificuldades para utilizá-los.

·         Depurador (Debugger): uma diferença no depurador do VS.NET consiste no fato de ele ser executado diretamente na IDE, o que o assemelha ao depurador do VFP quando executado no “FoxPro Frame”. Com relação às funcionalidades de utilização de breakpoints, execução de código linha-a-linha, definição de variáveis para serem visualizadas etc, são todas praticamente iguais. Um atrativo do depurador no VS.NET é a possibilidade de depurar código em uma aplicação Web.

·         Janela de Comando (Command Window): apesar de existir uma janela de comando no VS.NET, a janela de comando do VFP é muito melhor. Se comparadas, percebe-se que a janela de comando do VS.NET é limitada, algo que o desenvolvedor VFP definitivamente sente falta quando chega ao VS.NET.

·         Gerenciador de Projetos (Project Manager): no VS.NET, os projetos são trabalhados de maneira um pouco diferente dos projetos do VFP. No VFP, cada projeto é trabalhado separadamente e, se houver diversos projetos relacionados a um mesmo cliente, não existe uma forma fácil de lidar com isso (o VFP 8 traz o Environment Manager em seu Task Pane, mas ele ainda não é a forma ideal para este cenário). No VS.NET, existe uma janela chamada “Solution Explorer”. Basicamente, quando temos diversos projetos que se relacionam de alguma forma, unimos esses projetos em uma mesma solução, e é através do Solution Explorer que gerenciamos e trabalhamos com eles. Por exemplo, pode-se ter uma solução contendo os seguintes tipos de projetos: uma aplicação Web, uma aplicação Windows, um Web Service, um Serviço do Windows, e por aí vai. Vou falar um pouco sobre os tipos diferentes de projetos na próxima seção.

·         Janelas para edição de código e criação de telas: talvez a principal diferença nesse aspecto seja o fato de que, a exemplo do MS-Excel, no VS.NET todas as janelas abertas são agrupadas em “fichas” (tabs), e as pastas são abertas dentro de um arquivo (veja a Figura 1). As demais funcionalidades são muito parecidas, como cores diferentes para sintaxes, arrastar-e-soltar para criação de telas etc. Uma funcionalidade muito interessante presente no editor de código do VS.NET é a opção de expandir e retrair definições de blocos como métodos e classes. Isto facilita a visualização do código no arquivo e, ao parar o cursor do mouse sobre alguma região retraída, é exibido um tooltip (dica de ferramenta) que mostra parte do código que está escondido (Figura 2).

 

image002.jpg

Figura 1 Visual Studio.NET

 

image004.jpg

Figura 2 Editor de Código e a opção de expandir ou retrair blocos de código.

 

Existem diversas outras janelas e características similares entre os dois ambientes, mas acredito serem estas as mais utilizadas no dia-a-dia pela maioria dos desenvolvedores.

Um ponto importante a ser ressaltado é que o VS.NET suporta nativamente as linguagens C#, VB.NET e C++. Assim como no VFP, é possível criar virtualmente qualquer tipo de add-in para o VS.NET, como construtores (builders) e assistentes (wizards) (que ajudam na criação de classes customizadas) para oferecer ao desenvolvedor opções que não existam originalmente no produto.

Não há dúvidas de que o desenvolvedor VFP recém-chegado ao VS.NET vai estranhar diversas coisas, mas em linhas gerais, é só uma questão de adaptar-se às diferenças.

 

IDE para diversos tipos de projetos

No VFP, só é possível criar um tipo de projeto. Este projeto pode ser uma aplicação Windows, uma biblioteca de classes (app) que serão consumidas por alguma outra aplicação, ou uma biblioteca de classes compiladas como componentes COM. Já no VS.NET, isto é bastante diferente: existem diversos modelos (templates) diferentes para vários tipos de projetos. Por exemplo, existem modelos para aplicações Windows, aplicações Web, Web Services, aplicações de console, serviços do Windows, biblioteca de classes, aplicações para dispositivos móveis, etc. Quando você cria um novo projeto, automaticamente são gerados e adicionados a ele os principais arquivos que ele utilizará.

Avançando um pouco mais, é possível também desfrutar de “Enterprise Templates”, onde uma empresa pode criar seu próprio modelo para projetos específicos e determinar quais arquivos e recursos deverão ser adicionados (como Frameworks, controles ActiveX, etc.) ao projeto ou solução criada a partir dele. Isso facilita a configuração inicial para a criação de novos projetos.

É importante lembrar que o VS.NET é um ambiente unificado, onde se pode criar aplicações dos mais diversos tipos, ao passo que, infelizmente, isso não ocorre no VFP.

Common Language Runtime (CLR)

 

Toda aplicação VFP necessita da biblioteca runtime do VFP. Por exemplo, as aplicações .NET necessitam do CLR para serem executadas. O CLR possibilita a execução de código escrito em qualquer linguagem .NET. Desse modo, qualquer aplicação escrita em VB.NET, C#, C++, ou qualquer outra linguagem .NET poderá ser executada sob o CLR.

Todo código executado pelo CLR é chamado de código gerenciado (managed code). Isto significa, por exemplo, que todo o controle de memória e segurança é controlado pelo CLR, o que torna as aplicações mais estáveis.

O CLR permite escrever classes em uma linguagem (por exemplo C#) e subclassificar essas classes em outras classes escritas em VB.NET. Isto permite subclassificar uma classe criada em linguagem .NET em qualquer outra linguagem .NET.

 

.NET Framework

 

O .NET Framework é um conjunto de classes (mais de 2.500) que oferecem diversos tipos de funcionalidades e serviços para aplicações. Muitos desenvolvedores VFP questionam qual a melhor linguagem .NET ao darem os primeiros passos na plataforma. Na realidade, a escolha da linguagem não é o ponto mais importante. É o aprendizado do .NET Framework que realmente deve receber a maior atenção.

Obviamente, não se deve tentar memorizar e aprender a utilizar as mais de 2.500 classes. Isto seria um absurdo. O mais importante é familiarizar-se com as classes mais comumente utilizadas, como as classes para acesso a dados (conhecidas como ADO.NET), as classes para desenvolvimento Web (ASP.NET) e algumas classes para XML, Web Services, tratamento de strings, etc.

O que você deve aprender é como as classes estão organizadas, a fim de que saiba localizar uma determinada classe no momento em que precise dela. Para isso, é necessário compreender Namespaces, parte da próxima seção.

 

Namespaces

 

Em face do grande número de classes existentes no .NET Framework, bem como do grande número de classes criadas pelo desenvolvedor ao gerar novas aplicações, é necessária uma forma lógica para organizar todas as classes. Aqui entram os Namespaces.

No VFP, podemos organizar classes através de bibliotecas de classes em arquivos PRG ou VCX.  Entretanto, essa é uma organização apenas física, ou seja, determina apenas onde cada classe está armazenada fisicamente. Não existe nenhuma forma de agrupar classes de maneira lógica. Se existirem duas classes de nome Produto armazenadas em bibliotecas diferentes (por exemplo MinhasClasses.PRG ou MinhasClasses.VCX), qualquer tentativa de instanciar a classe Produto será confusa porque o runtime não saberá qual das classes utilizar, a menos que o desenvolvedor especifique explicitamente em qual dos arquivos procurar. No .NET, este potencial problema é resolvido por meio da criação de Namespaces.

As classes que têm relação entre si - por prover um mesmo tipo de serviço específico - são agrupadas em um determinado Namespace. Um Namespace pode conter não só classes como também outros Namespaces, possibilitando assim um ótimo nível de granularidade no agrupamento lógico de classes. A Figura 3 mostra uma representação gráfica parcial do Namespace System.Drawing. Pode-se ver que esse Namespace agrupa algumas classes como Bitmap, Brush, Brushes, ColorConverter, etc., além de outro Namespace chamado Printing, que por sua vez possui classes como InvalidPrinterException, Margins, etc.

 

image005.gif

Figura 3 Agrupamento lógico de classes em Namespaces.

 

Diferenças sintáticas

 

Apesar de o VS.NET suportar nativamente as linguagens VB.NET, C# e C++, o desenvolvedor VFP normalmente optará pela utilização do VB.NET ou C# (ou ambos), visto que C++ é a linguagem que mais difere do VFP. Sendo assim, abordarei algumas diferenças entre VFP, VB.NET e C#.

Muitos consideram o VB.NET o caminho natural para o desenvolvedor VFP dentro do .NET, em face das diversas similaridades entre as duas linguagens. Entretanto, o que se vê no mercado de trabalho é que a maioria de desenvolvedores opta pelo C#. Os motivos são os mais diversos, e não tenho intenção de abordá-los neste artigo. Por enquanto, o leitor deve apenas entender que o mais importante no .NET é aprender a utilizar as principais classes disponíveis no .NET Framework, pois a partir daí as principais diferenças entre as linguagens serão apenas nas áreas de sintaxe e em algumas particularidades existentes em uma linguagem e na outra não. Enfim, todas as linguagens utilizam as mesmas classes do .NET Framework, e a escolha da linguagem será uma questão pessoal ou de imposição de empregadores, clientes, ou algo assim.

Assim como o VFP, o VB.NET não é uma linguagem case-sensitive, e MinhaVariavel e minhavariavel podem indicar o nome da mesma variável. Por outro lado, o C# é uma linguagem case-sensitive, o que significa que no exemplo acima mencionado existem duas variáveis completamente diferentes (MinhaVariavel e minhavariavel).

Outra diferença encontrada em C# é a necessidade de incluir um ponto-e-vírgula (;) para indicar o final de uma linha de comando. Isto é confuso para o desenvolvedor VFP porque no VFP o ponto-e-vírgula serve como indicação de que a linha de comando continua na linha seguinte. Posso dizer que se acostumar a isso é uma questão de hábito, e o desenvolvedor superará essa diferença facilmente após algum tempo.

A Listagem 1 mostra as diferenças sintáticas no que se refere ao bloco de decisão IF:

 

·         Entre VFP e VB.NET, a principal diferença é a palavra-chave EndIf (VFP) e End If (VB.NET, já que no VFP ela é uma única palavra e no VB.NET são duas palavras separadas. No caso do C#, não existe tal palavra-chave. Praticamente todos os blocos de código em C# estão entre chaves ({}), o que confere grande consistência à linguagem.

·         A palavra-chave Then é obrigatória em VB.NET, enquanto no VFP, embora ela seja suportada, não é obrigatória e, por isso, praticamente não é utilizada.

·         Em C#, a condição testada deverá sempre estar entre parênteses.

 

 

Listagem 1 Blocos IF em VFP, VB.NET e C#.

VFP

 

If Condicao

    MessageBox(“Verdadeiro”)

Else

    MessageBox(“Falso”)

EndIf

 

VB.NET

 

If Condicao Then

    MessageBox.Show(“Verdadeiro”)

Else

    MessageBox.Show(“Falso”)

End If

 

C#

 

if (Condicao)

{

    MessageBox.Show(“Verdadeiro”);

}

else

{

    MessageBox.Show(“Falso”);

}

 

Declaração de variáveis apresentam uma importante diferença. Veja o seguinte código:

 

VFP

 

LOCAL Nome

 

VB.NET

 

Dim Nome as String

 

C#

 

String Nome;

 

Em primeiro lugar, a declaração de variáveis em VFP não é obrigatória, pois ao se referenciar uma variável que ainda não tenha sido declarada, esta será declarada com escopo privado (visível para a rotina que a declarou e para todas as outras rotinas chamadas a partir dela). No entanto, para este exemplo, a variável Nome é declarada usando-se a palavra-chave LOCAL. Este mesmo procedimento é similar tanto no VB.NET como no C#, e as diferenças são sintáticas (no VB.NET utiliza-se a palavra-chave Dim, enquanto no C#  não existe uma palavra-chave específica para isso, além do já mencionado ponto-e-vírgula).

E por que não existe uma palavra-chave para determinar o escopo de uma variável nas linguagens .NET? Pelo simples motivo de que toda e qualquer variável em .NET sempre terá visibilidade local, isto é, só é possível acessá-la dentro da rotina em que ela foi criada. Não existem variáveis públicas ou privadas em .NET.

Outra diferença importante: tanto em VB.NET como em C# o tipo da variável é declarado como String. O fato importante aqui é que as linguagens .NET devem utilizar tipagem-forte, o que significa que todas as variáveis deverão ser declaradas como um tipo específico e cada variável só poderá armazenar conteúdos que sejam do mesmo tipo daquele declarado. Nota: no VB.NET, por razões de compatibilidade-retroativa, é possível burlar essa limitação, mas a declaração de variáveis sem especificação de tipo não é uma boa prática.

Por outro lado, no VFP, apesar de ser possível declarar uma variável especificando seu tipo, isso só é necessário para suportar o mecanismo de IntelliSense, e nenhum erro de compilação ou execução será gerado quando se tentar atribuir um valor numérico a uma variável declarada como tipo string, por exemplo.

É impossível listar aqui todas as diferenças sintáticas dessas três linguagens, e o mais importante é enfatizar o fato de que todas são similares no que se refere à declaração de variáveis, blocos de decisão e loops no código, além das demais características fundamentais para qualquer linguagem de programação. Tudo que o desenvolvedor VFP precisa é ir ao Help das linguagens .NET e procurar a sintaxe apropriada às suas necessidades específicas. 

 

Tratamento de erros e exceções

 

Os desenvolvedores VFP sempre foram acostumados a tratar erros com o comando ON ERROR e o evento Error disponíveis em todas as classes-base até a versão 7.0. No VFP 8.0, inspirado pelo .NET, foi introduzido na linguagem o tratamento estruturado de exceções, implementado através dos blocos TRY/CATCH/FINALLY.

Mais uma vez, a diferença entre o VFP, o VB.NET e o C# no que se refere ao tratamento de exceções ocorre principalmente na sintaxe. Existem algumas sutis diferenças na implementação do VFP, mas os detalhes sobre elas podem ser encontrados no Help do produto.

É importante salientar que o .NET não oferece equivalentes para o ON ERROR e para o evento Error do VFP, portanto, é necessário que o desenvolvedor esteja bem familiarizado com os blocos TRY/CATCH porque eles são a única forma de tratar exceções no .NET.

 

Programação Orientada a Objetos (POO)

 

O VFP sempre foi uma linguagem híbrida, que possibilita escrita de códigos procedural e orientado a objetos. Os desenvolvedores VFP que não escrevem código orientado a objetos têm grande dificuldade para dar os primeiros passos no .NET devido à inexistência de código procedural nesta plataforma. O VB.NET, mais uma vez por questões de compatibilidade-retroativa, possibilita a criação de módulos que, apesar de parecerem códigos procedurais, serão ao final convertidos em classes pelo compilador. Por isso a afirmativa “No .NET, absolutamente tudo é objeto”.

Desse modo, os desenvolvedores VFP habituados a escrever código orientado a objetos não terão maiores problemas para criar e utilizar classes em .NET. Todas as características da POO presentes no VFP estão também presentes no .NET: herança, encapsulamento, abstração, polimorfismo, métodos, propriedades, enfim, está tudo lá.

Na verdade, o .NET possui uma implementação ainda melhor da POO, como classes verdadeiramente abstratas (classes marcadas como abstratas jamais podem ser instanciadas), definição e implementação de interfaces de maneira mais limpa, etc.

Uma comparação detalhada das diferenças entre o VFP e o .NET no que se refere à POO pode ser encontrada em http://www.eps-cs.com/pdf/whitepaper_vfp310.pdf e nos artigos publicados mensalmente na revista FoxPro Advisor (http://foxproadvisor.com/).

 

Acessando dados com o ADO.NET

 

Um dos destaques do VFP consiste nos comandos e funções nativas para acesso a dados, bem como na capacidade de criar cursores locais para processamento de dados. Não são necessários componentes externos para se trabalhar com dados armazenados em tabelas VFP (arquivos DBF). Se os dados estiverem em RDBMS (SQL Server, Oracle, etc.), só será preciso o driver ODBC correspondente, pois existem funções nativas para você se conectar ao banco e executar comandos SQL.

Entretanto, nas aplicações construídas em arquitetura multicamadas, o desenvolvedor acaba utilizando Recordsets ADO ou documentos XML para passar os dados entre as diversas camadas da aplicação. Geralmente, é difícil para o desenvolvedor VFP acostumar-se com o ADO e ver os dados na forma orientada a objetos. O desenvolvedor habituado não terá dificuldades em aprender o ADO.NET. Deve-se mencionar que o ADO.NET apresenta diversas diferenças com relação ao antigo ADO, mas o conceito de acesso a dados por meio do POO é o mesmo. Aqueles que não têm nenhuma experiência em ADO se sentirão num mundo totalmente estranho e terão saudades do VFP, mas essa realidade precisa ser encarada.

 

Conclusão

 

Neste artigo, procurei dar ao leitor uma visão geral do .NET sob o ponto de vista de um desenvolvedor VFP. Foram apresentadas algumas das principais diferenças entre o VFP e o .NET, mas o assunto é bastante vasto para ser abordado em mais detalhes em apenas um artigo. Desse modo, gostaria de recomendar alguns recursos valiosos (além dos já mencionados no artigo) para o desenvolvedor VFP conhecer o .NET:

 

Livro: .NET for VFP Developers, de Kevin McNish, Ed. Hentzenwerke (em Inglês)

http://www.hentzenwerke.com/catalogpricelists/netvfp.htm

Até o momento, este é o único livro publicado sobre o assunto (.NET para Desenvolvedores VFP). Kevin é o criador dos frameworks Mere Mortals for Visual FoxPro e Mere Mortals .NET e é bastante conhecido na comunidade VFP. Leitura obrigatória!

 

Forum de .NET no Universal Thread (em Inglês)

http://www.universalthread.com/Net/

A maioria dos participantes deste fórum é formada por desenvolvedores VFP, portanto, este é um ótimo veículo para troca de informações com esses profissionais (que também utilizam o .NET como ferramenta de trabalho).