Migrando arquiteturas para o .NET
Muito se fala no processo de migração para o .NET . Migrar aplicações inteiras para o .NET, etc. Vamos dar um enfoque um pouco diferente ao assunto : Qual o impacto de diferentes arquiteturas de desenvolvimento em sua migração para o .NET ?
Vamos analisar uma a uma, arquitetura Desktop, client/server, web, N-Tiers e WebServices
Desktop
De fato não sei se este nome é formal, é o nome pelo qual costumo chamar pequenas aplicações que fazem acesso a bancos ISAM, ou seja, bancos baseados em arquivos tal como Access, dbase, etc.
Uma característica destes bancos é que não existe servidor para que seja dividida a carga de processamento, assim sendo todos os dados são processados no client. Tarefas como filtragem de dados, ordenação, pesquisas, entre outras, são todas feitas na máquina do usuário.
Em termos de ADO fala-se que estamos utilizando o cursor no client, ou seja, o ponteiro de registros é mantido na máquina do usuário.
Porém a engine de gerenciamento de cursores no client do ADO não é muito eficiente, perdendo performance. A nova versão do ADO, o ADO.NET, tem uma engine de gerenciamento de cursores no client muito mais eficiente que a do ADO, além do fato de internamente guardar os dados em XML. Isso faz com que as aplicações Desktop, ao serem recriadas no ambiente .NET, ganhem performance.
Devido a arquitetura gerenciável do .NET é necessário que nas máquinas que vão utilizar a aplicação desktop o framework .NET esteja instalado. O Windows XP já está vindo com o Framework .NET incluido nele, uma vantagem para as empresas que mantém sempre a versão do sistema operacional atualizada.
Client/Server
Ao contrário das aplicações desktop, em aplicações client/server temos um servidor de banco ativo, tal como Oracle, Sybase ou SQL Server.
O ADO.NET traz uma otimização bem interessante para este ambiente : Traz mecanismos de acesso direto ao servidor SQL Server, não passando pelo OLEDB e, desta forma, realizando o acesso mais rapidamente. Assim sendo, da mesma forma que existem os objetos OLEDBConnection, OLEDBCommand e OLEDBDataAdapter existem também os objetos SQLConnection, SQLCommand e SQLDAtaAdapter.
Os mais observadores já devem ter notado um problema. Apesar do ganho de performance sempre ser vantajoso, o fato dos objetos serem diferentes para acesso via OLEDB e acesso direto ao banco prende a aplicação com um único servidor de banco. Caso em um futuro próximo a aplicação precise interagir com um servidor de banco diferente os objetos de acesso a dados terão que ser trocados, fazendo com que o que deveria ser uma simples troca de banco se transforme em uma grande maratona para alteração da aplicação.
Assim sendo, ao montar uma aplicação que faça acesso a um servidor de dados no .NET devemos estar atentos a isso : O que é melhor, obter maior performance ou portabilidade em relação ao banco ? Não existe uma resposta certa, deve ser analisado de acordo com as características do negócio da empresa.
Outro problema em aplicações client/server é a utilização do RAD (Rapid Application Development). Os recursos de RAD, tal como componentes vinculáveis, Grid's, entre outros, criam uma interface padrão que poderia gerar perda de performance devido ao tráfego. Basta imaginar uma grid vinculada a uma tabela de 10.000 registros : Se todos os registros tiverem que ser carregados na grid existe ai uma grande perda de performance, perda mesmo, já que os usuários não olharão nem para 1 décimo disso.
Para resolver esse problema no VB 6 tinhamos os cursores no servidor e o controle de cachesize no recordset. Assim sendo poderíamos fazer a grid e manter os dados no servidor. O servidor só faria o envio de dados para o client conforme o usuário navegasse pela grid, ou seja, conforme os dados fossem realmente necessários.
Essa prática sempre teve seus críticos. Cursores no servidor geram tabelas temporárias no servidor de banco, que consomem recursos e por isso prejudicam a escalabilidade do ambiente client/server. Sempre houve aqueles que disseram que se ao invés de utilizar RAD as interfaces fossem melhor planejadas para que pudessem utilizar cursores no client trazendo para a máquina do usuário apenas os dados dos quais esse realmente necessitasse a aplicação seria bem mais escalável. Mas mesmo esses criticos sempre tiveram que admitir que para algumas aplicações o custo/benefício de ter que fazer uma grande codificação para evitar os cursores no servidor não era vantajoso.
Agora, com o .NET, este problema resurge. O ADO.NET, para surpresa de todos, não suporta cursores no servidor. Antes do lançamento do VB.NET houve quem dissesse que o ADO.NET não era um substituto para o ADO, mas que foi feito para trabalhar em conjunto com este. Enquanto o ADO.NET com seus cursores no client e desconectados e sua manipulação interna em XML é excelente para o ambiente WEB o ADO com seus cursores no servidor continuaria funcionando bem para client/server.
Mas com o lançamento do VB.NET não foi isso que ocorreu. O VB.NET tem todo seu RAD direcionado para o ADO.NET, ele não é capaz de fazer RAD com ADO, o que significa que aplicações RAD criadas com o VB.NET terão que utilizar cursores no client.
Desta forma, ao criar uma grid ou uma tela de navegação todos os registros são transferidos para o client. Isso exige um alto planejamento e codificação para contornar esse problema e invalida o uso de RAD. A perda de performance que o uso de RAD no .NET trará para aplicações client/server será alta.
Existe, sim, possibilidades de contornar isso para, enfim, montar aplicações client/server no VB.NET :
A) Em primeiro lugar a interface teria que ser re-planejada. Nada de abuso de grid's ou telas com barras de navegação. Deve-se fazer muita filtragem de registros, uso de TOP's em selects, etc., tudo para garantir que o mínimo possível de registros sejam trazidos para o client. Mas tenha o cuidado de verificar se mesmo assim vc não estaria trazendo registros demais. Por exemplo, se você tem uma tabela com 1 milhão de registros, até onde conseguirá fazer a filtragem ? 30.000 ? Ainda é um volume grande em termos de tráfego de rede.
B) Como opção complementar existe a possibilidade de trabalhar com os objetos do ADO dentro do VB.NET, via código. Assim sendo você poderia, via código, obter dados utilizando cursor no servidor e gerenciar a exibição destes dados.
C) Técnicas de paginação também poderiam ser utilizadas. Em um artigo que li a própria Microsoft recomenda como solução para os desenvolvedores que utilizam Grid's que estes desenvolvam suas próprias técnicas de páginação utilizando o objeto DataSet.
Vale mencionar ainda que a Microsoft tem prometido inserir o recurso de cursores no servidor no ADO.NET em futuras versões deste. Mas o recurso será criado apenas para servidores SQL Server.
Tendo em vista essas características é muito importante, ao planejar a migração de uma aplicação client/server para o .NET, levar em consideração o re-planejamento da interface gráfica ou uma possível mudança de arquitetura da aplicação.
Web
A arquitetura Web só possui ganhos. Veja :
O ASP.NET tem melhor performance que o ASP por trabalhar com código compilado para a IL (linguagem intermediária)
A programação no ASP.NET é mais simples que no ASP, utilizando-se tags como se fossem objetos e tais tags sendo substituidas pelo próprio ASP.NET pelo código html/javascript para fazer determinada tarefa, tal como a valição de dados, por exemplo.
Os cursores no client do ADO.NET e o uso interno que este faz do XML garante maior performance que o atual ADO.
O objeto DataSet do ADO.NET pode ser mantido em sessão sem os prejuizos para a escalabilidade que isso normalmente acarretaria. Fica então muito mais fácil manter estado através das páginas ASP.NET
Entre inúmeras outras vantagens. Realmente a programação para Web, que com o ASP parecia ter regredido uns 10 anos em técnicas de programação (afinal o ASP muito se assemelha a um código modular) deu agora um grande salto evolutivo.
Já existem provedores gratuitos e pagos dando suporte ao uso de ASP.NET. O Brinkster, por exemplo, é um deles.
N-Tiers
É fato que ainda não existe um servidor de aplicações para os componentes CLS utilizados no .NET. Estes componentes foram criados para serem uma evolução do COM, mas ainda não existe um servidor de aplicações, tal como o COM+ para o COM, que suporte os componentes CLS.
Por isso os componentes CLS, para poderem fazer uso de serviços de um servidor de aplicações, são encapsulados na forma de componentes COM utilizando para isso o namespace System.EnterpriseServices .
Se por um lado o encapsulamento de componentes CLS dentro de componentes COM dão a impressão de serem uma grande "marreta" para contornar a temporária falta de um servidor de aplicações para componentes CLS, por outro lado isso traz uma real vantagem de performance : O encapsulamento é realizado com um componente COM Free Threaded, ao invés do Apartment Threaded como acontece com o VB 6, o que faz a performance ficar melhor que a dos componentes produzidos com VB 6.
A facilidade do .NET em inserir componentes no COM+ e fazer uso de componentes COM cria diversas possibilidades de migração : Pode-se migrar a interface sem migrar componentes, pode-se migrar componentes sem migrar a interface e pode-se fazer uso conjunto de componentes criados no VB 6 com componentes criados no .NET
O inconveniente da criação de componentes no .NET é o fato de que é o próprio .NET que realiza a criação do package no COM+ no momento em que o componente é registrado. As informações para criação do package são inseridas no código do componente e no AssemblyInfo.
O fato das configurações serem feitas em código transfere para desenvolvedores tarefas hoje realizadas por equipes de suporte. O package pode ser reconfigurado posteriormente, claro, mas os componentes não podem, por exemplo, serem trocados de package, o que exige que equipes de desenvolvimento já acostumadas com o COM+ reorganizem seu trabalho, se adaptando a essa nova característica.
WebServices
A tecnologia dos WebServices trouxe grandes recursos para a integração de aplicações via Web, utilizando XML para troca de dados.
Pouco antes do surgimento do .NET a Microsoft disponibilizou o SOAP Toolkit, que facilita a criação de WebServices com os componentes criados no VB. Mas isso não se compara a simplicidade com que podemos criar WebServices no .NET
Conclusão
O .NET traz muitas melhorias para as arquiteturas de desenvolvimento de software, mas exige um grande planejamento na hora de escolher a arquitetura mais adequada para sua aplicação
Conheça mais sobre o nosso site :
Dennes Torres
MCSD,MCSE,MCDBA
