O problema começa quanto existe centenas ou milhares de arquivos a serem armazenados, por exemplo, as diversas monografias geradas pelos alunos de uma universidade. Armazenar é fácil. Basta copiar o arquivo gerado em uma pasta de um CD, por exemplo e guardar este CD em local seguro. Se existe milhares de arquivos espalhados em vários CDs, a dificuldade aparece quando se deseja encontrar um arquivo específico que pode estar em qualquer dos CDs. Possivelmente todos os CDs precisarão ser investigados para localização de um arquivo específico. A complexidade aumenta se a necessidade for por encontrar um arquivo que possua um certo conteúdo. Cada CD será investigado e, ainda, cada arquivo presente no CD precisará ser aberto e lido na tentativa de se identificar o assunto ou conteúdo tratado no arquivo.

Seria muito pertinente se houvesse um sistema indexador desses arquivos, ou seja, um sistema que fosse possível armazenar a localização e identificação de cada CD, bem como os arquivos que o compõe. Além disso, um resumo dos dados do arquivo poderia ser armazenado para facilitar a identificação do seu conteúdo. O sistema poderia, também, realizar pesquisas ou filtros para identificar quais arquivos satisfazem às condições passadas.

A utilização de um sistema indexador como apresentado acima já resolveria o problema de pesquisa de arquivo, aumentando a velocidade de localização. Uma vez realizada a pesquisa e localizado o arquivo procurado, basta identificar o CD onde o arquivo está e ir até ele para copiar o arquivo procurado. A questão agora é ter que ir ao CD ou qualquer outro dispositivo de armazenamento para acessar o arquivo. Poderia ser interessante que o sistema citado acima pudesse armazenar uma cópia desse arquivo. Assim não haveria necessidade de recorrer a nenhum meio físico para cópia e resgate do arquivo. Note como isso abre várias possibilidades de uso: os arquivos podem ser criados a partir de documentos, ou seja, documentos em papel podem ser transformados em arquivos digitais e serem armazenados no sistema. Esse procedimento poderia ser muito útil em escolas para armazenamento de trabalhos de alunos, fóruns judiciários para controle de processos, hospitais para armazenamento de prontuários ou qualquer lugar que gere documento que necessite de guarda prolongada. Assim o arquivo físico poderia está guardado em local seguro e o arquivo digital poderia está no sistema para leitura e impressão quando necessário. Recorrer ao arquivo físico, só quando necessário. Associado a tudo isso poderia-se utilizar algum tipo de certificação digital para garantir a validade legal do arquivo digital, mas isso é uma outra história.

De fato, um sistema capaz de armazenar arquivos é muito útil para várias aplicações. Já deve estar claro que o sistema estará fazendo o armazenamento dos arquivos e informações em um banco de dados e, assim, todos os conceitos e recursos relacionados a SGBD (Sistema Gerenciador de Banco de Dados) estão disponíveis e envolvidos no sistema. Uma grande vantagem dessa abordagem é a realização de cópia de segurança para evitar perdas; os backup’s. Passa a ser uma responsabilidade do SGBD garantir a segurança da informação e evitar perda de dados ou dos arquivos armazenados.  Quando for feito o backup do banco de dados, diretamente está sendo feito o backup dos arquivos armazenados nesse banco. A periodicidade desses backups e o local armazenado são fatores importantes que podem garantir a recuperação de dados quando ocorrer alguma falha de hardware.

Para demonstrar essa ideia, desenvolvemos o ARQDOC – Armazenamento de Documentos em Banco de Dados. Este sistema permite guardar em banco de dados arquivos diversos. O próprio usuário pode categorizar seus arquivos, associar, se for o caso, a um documento físico armazenado em uma sala e importar o arquivo digital correspondente para o banco de dados do sistema. Posteriormente o usuário pode usar o SGBD para realização de backups que estarão salvando seus dados de forma segura. O resgate de arquivos no ARQDOC também é muito simples: basta realizar pesquisa por nome do arquivo, resumo, autor, etc. Para maiores informações acesse http://reginaldojr.wordpress.com/sistemas-c-codigo-fonte/arquivamento-de-documentos-em-banco-de-dados/.

Uma questão interessante que surge é como calcular a distância e o tempo de viagem entre duas localidades de uma rota. Os resultados poderão, então, serem utilizados em sistemas específicos. A solução apresentada foi utilizar o Google Maps para traçar a rota e, então, fazer um data scraping ou raspagem de dados para extrair as informações do HTML gerado pelo Google Maps. Como já foi mencionado, o processo consiste em receber os tags HTML em uma variável string e procurar nessa string a informação desejada; no caso, a distância e o tempo de viagem da rota informada.

Para exemplificar e melhorar a compreensão do processo decidimos construir uma aplicação que realize o cálculo de distância e tempo de viagem entre cidades e municípios brasileiros. A solução consiste de um banco de dados com cadastro de estados e cidades brasileiras. O usuário seleciona a cidade origem e destino para que o programa possa, após alguns segundos, exibir a distância e o tempo de viagem entre as cidades selecionadas. O tempo total é calculado a partir de uma viagem de carro respeitando os limites de velocidade de cada trecho. A cada cálculo realizado o sistema armazena em um banco de dados os valores encontrados para que, nas próximas solicitações do mesmo trajeto a resposta seja imediata; sem a necessidade de recálculo.

Na realidade, nenhum cálculo é feito. O sistema faz apenas uma leitura das informações contidas na página web do Google Maps que contém os dados desejados. Por isso o sistema precisa estar sendo executado em computador conectado a internet. O algoritmo utilizado é, mais ou menos, o seguinte:

1) string origem = ‘nome_da_cidade_e_estado_origem’;
2) string destino = ‘nome_da_cidade_e_estado_destino’;
3) string url = string.Format(“http://maps.google.com.br/maps?saddr={0}&daddr={1}&z=1″, origem, destino); // URL de pesquisa no Google Maps
4) Verificar se já existe no banco de dados a distância e o tempo de viagem entre as cidades origem e destino. Se já tiver, vai para linha 11. Se não, continua na linha 5
5)  string textoUrl = HtmlPage.Read(url); // Faz a leitura do HTML da url e guarda em uma string
6)  Regex RegexObj = new Regex(“distance:’(?<VALOR>.*?)’”); // Criam uma expressão regular para localização do valor da distância na página
7) string distancia = RegexObj.Match(textoUrl).Groups["VALOR"].Value; // Efetua o casamento e extrai o valor correspondente a distância
8 ) RegexObj = new Regex(“time:’(?<VALOR>.*?)’”); // Cria uma expressão regular para localização do valor do tempo na página
9) string tempo = RegexObj.Match(textoUrl).Groups["VALOR"].Value; // Efetua o casamento e extrai o valor correspondente ao tempo
10) Salva os resultados encontrados (distância e tempo) correspondente a cidade origem e destino no banco de dados;
11) Exibe os resultados encontrados (distância e tempo) para o usuário;
11) Fim;

Este é o algoritmo utilizado na aplicação que desenvolvi. Note que na primeira pesquisa o sistema resgata os dados do Google Maps e salva no banco de dados (linhas 5 a 10). Nas próximas vezes que uma pesquisa for feita com as mesmas cidades, o sistema resgata os resultados diretamente do banco de dados. Isso dará mas rapidez ao processo, uma vez que muito raramente a distância e o tempo irá ser modificado.

Para saber mais sobre a aplicação desenvolvida acesse http://reginaldojr.wordpress.com/sistemas-c-codigo-fonte/distanciatempo-entre-cidades-brasileiras/.

Separei três recursos interessantes que podem ser utilizados para enriquecer os sites e facilitar a vida dos usuários:

1. Recurso para localização de uma localidade no mapa: se você tem um site na Internet que divulga serviços e/ou produtos, seria interessante facilitar o acesso dos usuários ao estabelecimento. Se a empresa recebe ligações de pessoas solicitando o ponto de referência para facilitar o acesso, que tal exibir um mapa no seu site apontando a localização do estabelecimento?
2. Recurso para exibir uma possível rota entre duas localidades: como complemento ao posicionamento do estabelecimento no mapa, pode-se mostrar um caminho para o estabelecimento. O site pode mostrar a localização do estabelecimento, solicitar a localização atual do cliente e traçar uma rota no mapa.
3. Recurso para cálculo de distância entre duas localidades e tempo de viagem: para quem trabalha com viagens pode ser interessante calcular, por exemplo, a distância entre duas cidades e tempo aproximado numa possível viagem entre elas. Além disso, utilizar essa distância para cálculos de diárias, reembolsos, etc.

Esses e outros recursos podem ser adicionados a qualquer site utilizando a API do Google Maps.  Claro que não é tudo tão simples assim. Por exemplo, no terceiro recurso sugerido, mostrar pelo Google Maps a distância entre duas localidades não é complicado. Mas, extrair essa distância para manipulação ou, por exemplo, armazená-la em um banco de dados, isso é mais complicado. A seguir, vamos mostrar como adicionar em um site os recursos citados acima utilizando a API Google Maps em Javascript.

Sugerimos utilizar o Visual Studio para realização dos experimentos. Porém, com as devidas adaptações, a maioria deles podem ser implementados em qualquer editor web. Não iremos tratar dos recursos e conceitos de desenvolvimento web e no Visual Studio. Deixamos a cargo de leitor pesquisar sobre o assunto: Visual Studio, desenvolvimento Web, HTML, CSS, Javascript, ASP.NET, Servidor WEB, etc. Vamos ao trabalho…

Na sua aplicação, crie uma página onde serão implementados os recursos do Google Maps. Para realização dos experimentos insira no corpo (entre as tags HTML <body> e </body>) da página as seguintes tags:

<script src=’http://maps.google.com/maps?file=api&v=2.x&key=‘ type=’text/javascript’></script>
<div id=”mapa” style=”width: 70%; height: 480px; float:left; border: 1px solid black;”></div>
<div id=”rota” style=”width: 25%; height:480px; float:right;”></div>

Note que na primeira linha tem o parâmetro KEY. Se você for utilizar esse recurso em um servidor WEB real, deverá primeiro registrar este servidor no site da Google e receber uma chave que permitirá que seu site exiba os mapas. A chave pode ser adquirida aqui.

Localização de uma Localidade no Mapa

Após as linhas inseridas anteriormente adicione o seguinte script:

<script type=”text/javascript”>
var map;
function initialize() {
map = new GMap2(document.getElementById(“mapa”));
map.addControl(new GLargeMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng( -12.977753,-38.507779), 15);
var textHtml = ‘<center><strong>Minha Marca</strong></center>’;
var textHint = ‘Minha Marca‘;
var marker1 = new GMarker(new GLatLng(-12.977753,-38.507779), { draggable: false, title: textHint });
marker1.openInfoWindowHtml(textHtml);
GEvent.addListener(marker1, “click”, function () {
marker1.openInfoWindowHtml(textHtml);
});
map.addOverlay(marker1);
}
initialize();
</script>

Este script irá utilizar a DIV ‘mapa’ para mostrar um mapa e colocar uma marca em um ponto específico. Note que em vermelho tem as informações de latitude e longitude correspondente à alguma localidade. Existe várias formas de se descobrir essas coordenadas correspondente à localidade. Leia este post e os comentários que foram colocados. Nele o autor sugere uma forma de descoberta das coordenadas de uma localização e os leitores comentam essa forma ao mesmo tempo que sugere outras formas para identificar essas coordenadas. Voce de ler e escolher a forma que ache mais conveniente para você. Uma vez encontrada essas coordenadas faça a substituição no local específico do nosso script. No texto em azul você pode inserir um texto identicador para a marca inserida. A figura abaixo mostra o resultado esperado.

Como você pode ver, podemos inserir scripts em Javascript para trabalhar com a API do Google Mapas e manipular a exibição de marcas dentro do nosso mapa.

Exibir uma Possível Rota entre Duas Localidades

Para inserir uma rota no mapa, substitua o script anterior pelo mostrado abaixo:

<script type=”text/javascript”>
var map;
var directionsPanel;
var directions;

function initialize() {
map = new GMap2(document.getElementById(“mapa”));
map.addControl(new GLargeMapControl());
map.addControl(new GMapTypeControl());
directionsPanel = document.getElementById(“rota”);
directions = new GDirections(map, directionsPanel);
directions.load(“from: Rua do Carro, Salvador – Bahia, Brasil to: rua jardim santo antonio, salvador bahia“);
}
initialize();
</script>

Em vermelho estão a localização de origem e destino. Se nessas informações, possuir alguma inconsistência ou erro de digitação o mapa não será mostrado. Por isso é importante acessar o site do Google Maps para fazer testes com a origem e destino e, assim, identificar a melhor grafia para origem e destino da rota. A figura abaixo mostra uma rota traçada.

Distância entre Duas Localidades e Tempo de Viagem

No item anterior mostramos como exibir uma rota no mapa e um detalhamento dos caminhos que podem ser utilizados para sair do ponto A e chegar ao ponto B. O resultado exibe ainda outras informações: a distância total entre a origem e o destino,  o tempo médio para percorrer os dois pontos e a distância entre os trechos intermediários no caminho entre a origem e o destino. Pode-se, também, na origem e destino informar nomes de cidades. O Google Maps irá calcular a distância entre as cidades e o tempo estimado do percurso. Para realizar operações com estes valores basta transcrevê-los para um sistema especifico e efetuar os devidos cálculos. Assim, a princípio, a questão de cálculo da distância entre duas localidades e o tempo estimado de transporte está resolvido.

Mesmo funcionando bem, o procedimento de copiar da tela do Google Maps para o sistema específico não me parece muito elegante. Primeiro que, por ser um procedimento com interferência humana, podem ocorrer erros na transcrição. Seria interessante que o próprio sistema se conectasse ao Google Maps e extraísse os valores necessários. Pesquisando na documentação da API do Google Maps não consegui identificar uma forma automática de fazer essa leitura dos dados. Se alguém souber como, por favor, deixe seu comentário para ajudar a nós, pobres mortais. Para tentar resolver esse problema tive que apelar para um processo não muito ortodoxo. A inspiração veio desse post. O autor utiliza o conceito de raspagem de dados, ou data scrapping, que é uma forma de extrair informações diretamente da tela do computador. Leia mais sobre isso aqui. Para o nosso caso fizemos uma “raspagem de HTML” que consiste em receber dentro de um sistema o HTML gerado pelo Google Maps e pesquisar na sequência de tags e caracteres onde está nossa informação; no nosso caso, a distância entre os duas localidades e o tempo aproximado de viagem. Essa pesquisa nas tags HTML pode ser de forma sequêncial, randômica ou utilizando Expressões Regulares para fazer o casamento de expressão. Nossa opção foi pelas Expressões Regulares por parecer ter uma melhor performance. Como desejamos manipular a informação em sistema específico não faz sentido utilizar o Javascript para obter o resultado. Por isso utilizamos a linguagem C# na plataforma .NET para realizar o processo de raspagem. Quem tiver alguma observação ou proposta diferente da nossa, favor deixar um comentário.

Acompanhe o próximo post onde estaremos modelando uma aplicação que utiliza este procedimento: Cálculo de Distância e Tempo de Viagem entre Cidades Brasileiras.

O programa foi desenvolvido em C# e .NET. O banco de dados utilizado é o Firebird. Contudo, o sistema pode ser modificado para utilização com qualquer banco de dados comercial.  A ferramenta de desenvolvimento da solução foi Visual Studio Profissional e pode ser aberta no VC# Express.

A solução foi desenvolvida em camadas e é composta de 5 projetos: um em Windows Forms, um para regras de negócios (BO), um para acesso a dados (DAO),  um para as interfaces e outro para mapeamento objeto-relacional. O projeto utiliza o NHibernate para persistência de dados.

Quem se interessar pode me mandar email ou acessar a página da aplicação para obter maiores informações.

A primeira decisão foi escolher a linguagem. No início optei pelo PHP. Open source, vasta documentação, inúmeros usuários, etc. Cheguei a construí alguns módulos do sistema nessa linguagem. Mas não fiquei satisfeito com o resultado. Do ponto de vista de apresentação nos navegadores dos usuários, nenhum problema. Tudo funcionava bem. Mas, do ponto de vista da manutenibilidade, surgiram alguns inconvenientes. As páginas misturam códigos HTML com PHP. Isso dificulta muito a compreensão para manutenção. Mesmo adotando boas práticas e algum nível de organização, é inevitável a mistura de códigos HTML e PHP. Posteriormente, analisando outras linguagens como o ASP, por exemplo, vi que em muiltas acontece a mesma coisa.

Duas opções surgiram: Java e .NET. Fiz alguns testes em cada uma das plataformas e optei pelo .NET, a plataforma da Microsoft. Estudei C#, ASP.NET e Visual Studio.NET. Ao longo dos anos desenvolvi várias soluções além de conseguir migrar a aplicação que deu origem a toda essa situação. Confesso que gostei muito dos resultados e desde então tenho me dedicado a esta plataforma. Por outro lado, uma coisa ficou clara pra mim: mais cedo ou mais tarde será necessário aprender Java.  Assim como em .NET, uma grande fatia do mercado de trabalho também utiliza a plataforma Java. Não é uma questão de utilizar a melhor plataforma ou quem pode mais. Em ambas pode-se conseguir o mesmo resultado: aplicações para dispositivos móveis, para ambientes distribuídos, para WEB,  para desktop, etc. Na realidade são características de cada ambiente que atraem os desenvolvedores. Enquanto .NET é independente de linguagem, o Java é independente de plataforma. Enquanto o desenvolvimento em  .NET envolve custos com ferramentas de desenvolvimento e sistema operacional, o Java é open source. O que fica claro é que .NET é um grande representante da tecnologia captalista, onde grandes empresas fazem investimentos visando obter altos lucros. O Java é um grande representante da tecnologia open source onde objetivo maior e a socialização do conhecimento em ambientes colaborativos. Uma complementa a outra. Uma funciona como reguladora para a outra. Cabe então a cada usuário escolher qual bandeira deseja levantar. No meu caso eu acho interessante conhecer e viver um pouco dos dois mundos. Nunca se sabe onde pode surgir uma boa oportunidade profissional.

Enfim, hora de aprender Java. Meu foco é desenvolvimento WEB. Meus estudos e pesquisas estão altamente focados neste objetivo. Nos posts a seguir vou registrar os caminhos que venho trilhando bem como os resultados obtidos na busca desse resultado. Espero estar contribuindo com o aprendizado de alguém. O primeiro passo dado foi LER. Procurei ler o máximo possível de apostilas e materias disponíveis na internet. Um link que encontrei com bastante conteúdo foi esse: http://www.4shared.com/dir/2121292/beead201/Apostilas_Java.html. Primeira coisa que procurei conhecer foi a linguagem: fluxos de controle, variáveis, expressões condicionais, etc. Não tive maiores problemas já que as linguagens C# que conheço razoavelmente bem e a linguagem Java são bastante parecidas. Uma pergunta que gostaria que voces me ajudasse a responder é: a semelhança dessas linguagens é mera coincidência ou C# foi inspirado no Java? Eu sei que ambas tem sua origem no C/C++. Mas será que C# aprendeu com o Java, levando em considerção que Java é mais velha? Será que C# nasceu aprendendo com os erros do Java? O que voces acham? Deixem seus cometários.

Bom… é isso e até o próximo.

Mas surgiu um problema: quem iria dar manutenção no site? EU? Sem chances!!!!!!! Foi aí que surgiu a idéia de construir um sistema gerenciador de conteúdo onde ele mesmo pudesse criar e gerenciar as páginas do site. A criação das páginas deveria ser bem simples, como se fosse um editor de textos. Procurei na Internet sistemas de CMS (Content Management System ou Sistema Gerenciador de Conteúdo) prontos que pudessem ajudar nessa tarefa e achei alguns: Blogs gratuitos, EVA (100% brasileiro), XOOPS, etc. Todos muito bons porém, para usuários com pouca ou nenhuma experiência, são exageradamente cheio de recuros. É bom que se diga, bons recursos. Mas para o meu problema, possivelmente eu tivesse que “dar um curso” de alguma dessas ferramentas para o usuário e o pior: ficar tirando dúvidas, etc. Sem falar nos problemas com a instalação do banco de dados.

Decidi construi algo mais simples, levando em consideração que o usuário só queria ter um local na Internet para divulgar informações. Construi o EDWS – Edição Dinâmica de WebSite. Esta primeira versão era bem limitada. Uma versão light. Tinha uns 3 layouts prontos, menu superior e lateral e dois recursos pré-formatados: uma página “Fale conosco” e uma outra para localização do estabelecimento no Google Maps. Adicionei também um contador de visita além de uns links para alguns serviços últeis: consulta de CEP e previsão do tempo. A edição das páginas era feita utilizando o FCK Editor. Já falei dele em posts anteriores. Documentação sobre este editor pode ser facilmente encontrado na Internet.

O fato é que o usuário ficou satisfeito e eu também. Ele fez o site e está no ar até hoje. Eu também gostei do resultado e decidi desenvolver outra versão para o EDWS. Nasce, então, o EDWS – Sistema de Gerenciamento de Conteúdo. Adicionei inúmeros outros recursos pré-formatados: blog, álbum, notícias, novos layouts, YouTube, etc.

Além de tudo, decidi disponibilizá-lo para quem desejar utilizar em seus trabalhos. Acho que o maior diferencial deste sistema é a simplicidade e facilidade de uso. Quem desejar conhecer mais sobre este sistema e baixá-lo pode acessar o blog que criei especialmente para este projeto: http://reginaldojr.wordpress.com/sistemas-c-codigo-fonte/edws/. Não há necessidade de adiquirir licença para utilizar a versão gratuita. Porém quem desejar suporte ou os fontes do programa poderá entrar em contato comigo para fazer-mos alguma negociação. A única limitação dessa versão gratuita é a exibição de um link para o blog do EDWS.

É isso!

Recentemente eu desenvolvi um sistema de gestão em saúde que utilizava esta tabela. O Datasus disponibiliza os dados desta tabela mensalmente em arquivos textos compactados. Tivemos que criar uma maneira de importar facilmente estes dados baixando do FTP e importando para o nosso banco de dados. O próprio usuário pode disparar este processo quando tiver conhecimento da disponibilidade das informações atualizadas da tabela.

Resolvi, então, disponibilizar a solução completa e com fontes para os interessados. Este projeto é bastante rico em recursos: criação de tabelas, descompactação de arquivos, download de FTP, conexão com banco de dados, execução de scripts DDL, etc. O projeto foi desenvolvido para utilização com banco de dados Firebird mas pode ser facilmente convertido para qualquer outro banco.

Acesse http://reginaldojr.wordpress.com/sistemas-c-codigo-fonte/importar-tabela-unificada-sus/ e tenha maiores informações sobre o nosso projeto.

É isso.

Em sistemas web não seria diferente. Afinal o acesso a páginas web pode ocorrer via intranet, ou seja, na rede local, ou pela internet passando por vários servidores, bandas, nós, comutadores, etc. É importante evitar submissões de páginas desnecessárias. Isso pode fazer com que a navegação seja bem mais rápida e produtiva. Por exemplo, se for definido na aplicação uma regra que somentes CPF´s válidos podem ser gravados no banco de dados, a aplicação deve validar o CPF antes de gravar no banco. Mas onde essa validação deve acontecer? Algumas sugestões:

1. Triggers na tabela – Antes do INSERT a trigger pode validar o CPF. O uso de trigger é desaconselhável, principalmente para validações de campo;
2. Procedures -  Se o sistema utilizar as procedures para implementar as regras de negócio, um ótimo lugar para validar o CPF é durante a execução da procedure;

Essa duas formas tem um problema em relação ao tráfego: os dados trafegaram a rede inteira apartir da tela do cliente até o banco de dados apenas para retornar “CPF inválido.”

Se utilizar um servidor de aplicação em uma arquitetura de n-camadas pode-se implementar a validação nos objetos de négocio. Isso já diminui um pouco o tráfego. Afinal o servidor de aplicação deve estar em uma camada acima, em relação a camada onde é feito o acesso ao banco de dados. O servidor de aplicação pode validar os dados e quando forem enviados à camada infeiror, os dados já foram validados na camada de regra de négocios.

Mas podemos subir camada ainda mais nessa validação. Podemos colocar a validação do CPF na camada de apresentação, exatamente no servidor web. Plataformas como PHP, ASP, ASP.NET, JSP podem utilizar essa forma. A página é submetida ao servidor web que faria a validação dos dados. Note que o servidor web deve ficar numa camada acima do servidor de aplicação.  Agora o tráfego é apenas entre o cliente e o servidor web que já é muito bom.

Mas tem certas validações que podem ser feitas diretamente no cliente; lá no navegador. Vejamos alguns exemplos:

• campos que não podem ser nulos;
• data, cpf, cns, cnpj, etc. inválidos;
• comparação de dados entre dos campos.

Ou seja, se determinadas validações, também chamadas de pré-validações, forem checadas antes de submeter a página ao servidor web podemos evitar ao máximo tráfegos desnecessários em situações elementares. O campo CPF pode ser validado antes de o usuário enviar os dados ao servidor, ou seja, a página só seria enviada ou submetida ao servidor se o CPF fosse digitado corretamente, com os dois dígitos verificadores válidos. O mesmo podemos pensar com datas, horas e outros valores. Assim a diminuição do tráfego seria total. A gravação do CPF, ao ser validado no navegador do cliente, quando fosse enviado ao servidor certamente seria gravado já que o CPF sempre estaria correto ao chegar no servidor. Isso vale para vários outros tipos de campos: data, hora, data e hora, cnpj, cns, números, campos com dígitos verificadores, entre outros.

Essa validação no cliente pode ser feita com Javascript. Uma problema: “E se o navegador não suportar Javascript?” Realmente. Aí a validação deverá também ser feita em alguma das camadas inferiores citadas acima. Foi dito que essas validações seriam um tipo de pré-validações. Nenhuma aplicação deve ser feita apenas com validações no navegador do cliente. Algum outro local deve fazer a validação principal. Os objetos de negócio devem implementar as validações dos campos. Em programação orientada a objetos isso passa a ser um requisito técnico. Se a validação no navegador do cliente não funcionar, a verificação em outra camada inferior deverá ser feita.

O fato é que validar no navegador do cliente utilizando Javascript é um boa prática para qualquer sistema web. Em ASP.NET existe alguns componentes que realizam essa tafera com muita qualidade.

• RequiredFieldValidator: usado quando um campo não pode ser vazio;
• RangeValidator: usado para verificar se o conteúdo do campo está dentro de uma determinada faixa;
• RegularExpressionValidator: usado para validar campos utilizando expressões regulares;
• CompareValidator: usado para comparar dois campos;
• CustomValidator: usado para preparar uma verificação personalizada;

Todos esses validadores fazem verificações diretamente no navegador do cliente e só deixa os dados serem enviados ao servidor se os dados estiverem de acordo com as condições definidas nos validadores. Existe mais um componente chamado ValidatorSummary que é capaz de exibir mensagens de erro durante a validação. Leia mais sobre esses validadores neste link.

Gostaria de destacar a utilidade do CustomValidator. Ele permite utilizar validações personalizadas em Javascript. O desenvolvedor pode criar alguma validação de acordo com sua necessidade.  Para utilizar este validador genérico a função em Javascript segue uma padronização na sua definição. O script para validação pode vir entre tags <scripts></scripts> na própria página ou em arquivos .js e vinculados a página. A função de validação pode ter qualquer nome sendo que os parâmetros de entrada devem ser source e arguments.  Veja o exemplo:

<script language=”Javascript”>

function valida_vazio(source, arguments)

{

// O campo não pode ser vazio

if (arguments.Value!=”")

{

arguments.IsValid = true;

return true;

}

else

{

arguments.IsValid = false;

return false;

}

</script>
O exemplo acima faz a mesma coisa que o RequiredFieldValidator: valida campos que não podem ser vazio. O CustomValidator faz referência a esta função na propriedade ClientValidationFunction. Voce pode também combinar validators. Por exempo: O RequiredFieldValidator pode ser usado para verificar que um campo não pode ser vazio e o CustomValidator para verificar se o campo foi preenchido com um CPF válido por exemplo.

Note que essas validações no cliente apenas verificam a qualidade dos dados digitados. Elas não verificam, por exemplo, se o CPF está ou não cadastrado no banco. Esse tipo de validação tem que ser feita do lado do servidor.

Diversos tratamentos e validações pode ser feitos utilizando Javascript e o CustomValidator. Veja alguns exemplos:

• CEP
• CNPJ
• CNS
• CPF
• Data
• Data/Hora
• Números decimal
• Dígito verificador
• Email
• Hora
• Números
• PIS/PASEP

Essas validações são comumente utilizadas na maioria das aplicações. Eu implementei cada uma delas em Javascript e construi uma página em ASP.NET que demonstra a utilização de cada uma delas com o CustomValidator.  Se desejar ver ou ter todas ou alguma dessas validações clique aqui.

Então é isso.

Por outro lado, os desenvolvedores de sistemas sabem da dificuldade de se construir um relatório. Isso sem falar das alterações que possam surgir posteriormente. Todos procuram alguma ferramenta que possa minimizar o desgaste natural causado pelo processo de construção e manutenção de relatórios. A situação tende a se agravar quando falamos de relatórios para sistemas web. Isso por que os navegadores trabalham com HTML. A situação natural é montar relatórios utilizando esta linguagem diretamente e isso não é tão trivial assim. Mesmo utilizando alguma outra linguagem que rode do lado do servidor o resultado final deve ser em HTML que é o que os navegadores são capazes de exibir. Para aumentar o poder desses navegadores alguns recursos podem ser utilizados: ActiveX, Plugins, Flash, Applets, etc. Essas e outras tecnologias, além de dar maior poder aos navegadores, aumentam a produtividade dos desenvolvedores já que podem utilizar ferramentas mais completas para gerar os relatórios que serão vistos nos navegadores.

Em .NET não seria diferente. Montar relatórios é um processo muito delicado. A pergunta é qual a melhor forma? Qual a melhor ferramenta? Resposta: EU NÃO SEI. Mas será que existe uma forma dita “melhor”?! Mas, como todo programador, eu também tenho a minha forma que pode não ser a melhor nem a mais ortodoxa. Mas é a minha forma e é com ela que tenho resolvido a maioria dos problemas. Vou compartilhar com voces.

A minha primeira experência em .NET foi quando eu tive que migrar um sistema do Delphi para o Visual Studio 2003. Neste sistema existe inúmeros relatórios. Inicialmente fiz as telas de usuário. Como o sistema em delphi utiliza as procedures de banco como regras de negócio não tive muitos problemas. Tive apenas que refazer as telas que iriam chamar as procedures. O problema começou na hora dos relatórios. Inicialmente tentei utilizar o Crystal Reports. Não me identifiquei com ele. Achei muito complicado e etc. A primeira solução que me veio a cabeça foi a seguinte: já que os relatórios estavam todos prontos em Delphi utilizando views e procedures do banco de dados decidi criar em Delphi um servidor de relatórios. O funcionamento era +ou- assim:

1. Um programa executavel criado em delphi e instalado no servidor encapsulava todos os meus relatórios. Este programa tinha a capacidade de exportar relatórios em PDF para a pasta web da minha aplicação.
2. Este programa era chamado de dentro da minha aplicação asp.net passando alguns parâmetros:  id-relatorio, arq-pdf-saida, param-1, param-2, … , param-n. O id-relatório identificava o relatório que eu gostaria de imprimir. Os parêmetros, de 1 a n, eram passados de acordo com a necessidade da instrução SQL do relatório.
3. O programa recebia estes parêmtros, conectava-se ao banco, extraia os dados do banco, montava o relatório e exportava para pdf em uma pasta com nome e path indicado pelo arq-pdf-saida.
4. A aplicação aguardava o término do processo até um certo limite e redirecionava o browser para o arquivo pdf gerado. Com o Adobe Reader instalado o navegador baixava este pdf e exibia ao usuário.

Durante muito tempo este sistema funcionou assim. Principalmente por que eu não tinha muito tempo para refazer toda aplicação inclusive os relatórios em 100% .NET utilizando o Crystal.

Mas, novas versões deste sistema foram surgindo e com elas, a necessidade de utilizar uma forma 100% .NET de fazer relatórios. Fiz algumas buscas e achei algumas ferramentas muito interessantes:

1. DevExpress
2. Afalinasoft
3. StimulSoft
4. PerpetuumSoft
5. (…)

Algumas eu testei e gostei. Todas são muito boas e integradas ao IDE do Visual Studio. Cada uma com suas características e diferenciais. Mas todas tem a principal limitação para o tipo de trabalho que eu faço:  não são gratuitas. Porém nada impede de utilizar a versão demo convivendo com algumas situações. Uma coloca o nome DEMO no meio de cada página impressa. Outra limita o número de páginas impressas. Outra coloca uma pequena propaganda no final da página. Enfim…. Pra mim era inviável.

Há também quem prefira fazer relatórios em HTML para exibir diretamente no navegador. Separei também um link para esses programadores: http://www.webly.com.br/tutorial/net/8861/aspnet-gerar-relatorio-em-html.htm.

Foi quando eu conheci o ReportViewer. Estudei um pouco sobre ele. Dê uma olhada nos endereços abaixo e conheça também um pouco mais:

1. http://www.macoratti.net/aspn_grv.htm
2. http://www.devmedia.com.br/articles/viewcomp.asp?comp=5371
3. http://blog.adsystems.com.br/2009/04/10/tutorial-c-relatorios-master-detail-com-reportviewer/
4. http://www.macoratti.net/08/03/vbn5_rpv.htm
5. http://www.macoratti.net/08/03/vb8_rpv2.htm
6. http://csharpbrasil.com.br/2008/09/11/criando-relatorio-com-reportviewer-em-aspnet/

Não vou entrar em detalhes do funcionamento. Os links acima são bem explicativos.  Mas duas novas questões surgem:

1. Eu não gostaria de utilizar o visualizador padrão do ReportViewer. Gostaria de exportar os relatórios diretamente para pdf para utilizar o Adobe Reader como visualizador no prórprio navegador.
2. Gostaria da utilizar o NHibernate como minha fonte de dados também. O natural é conectar o banco com algum DataSource. Gostaria que os dados viessem da minha camada de negócio (BO) e não conectando diretamente o banco. Principalmente pelo fato da independência de dados que já comentei e posts anteriores.  Sem falar no fato de obedecer as regras da arquitetura em camadas.

Graças a Deus, consegui resolver os dois problemas. Não pretendo construir um tutorial para cada solução.Vou passar a idéia da solução. A implementação da proposta fica como exercício para o leitor.  É necessário ter conhecimento intermediário de OOP, persistência com NHibernate, Visual Studio e arquitetura em camadas. Em posts atenteriores dou uma ajuda nessas questões. Vale a pena dar uma olhada.

Vamos ao que interessa.

1. Os relatórios desenvolvidos com ReportViewer podem ter como fonte de dados os DataTables. Esses DataTables podem ser criados tanto em tempo de execução quanto em tempo de desenvolvimento. Para nossa proposta é legal criá-los em tempo de desenvolvimento. Isso irá facilitar a confecção do arquivo de relatório (.rdlc). Faça isso. Abra um projeto no VS e adicione um item DataSet. Neste DataSet adicione um DataTable. As colunas do DataTable serão os campos que vc irá imprimir. Adicione as colunas com seus respectivos nomes.
2. Adicione um novo item ao seu projeto. Este item deve ser um Report (.rdlc). Agora voce deverá formatar o relatório de acordo com sua necessidade. Os links acima dão uma ideia de como trabalhar com a IDE. Uma coisa importante: as colunas do seu relatórios devem ser vindas do DataTable que voce criou no item anterior. Mas para que seja possível fazer essa associação voce deve vincular o relatório ao DataTable. No menu Report, selecione o DataSource. Na caixa suspenda selecione o DataTable que voce criou indicando-o como fonte de dados do relatório. A partir daí voce já pode adicionar colunas ao seu relatório.
3. Talvez vc queria indicar algumas informações no cabeçalho do seu relatório, tais como: nome da empresa, período, setor, etc. Isso deverá ser passado ao relatório através de parâmetros. No menu Report->Report Parameters voce pode indicar todos os parêmetros que desejar e posicioná-los no cabeçalho do relatório.

Neste relatório voce pode definir: grupos, sumários, totais, gráficos, tabelas com números de linhas e colunas variáveis, etc. Consulte documentação do ReportViewer.  Com um pouco de prática tudo vai parecer muito natural. No início eu támbem demorei um pouco a me familiarizar com o ambiente. Há quem diga que no ReportViewer não dá pra fazer relatórios muito complexos. Para os relatórios do dia a dia tenho tido ótimos resultados. Sem falar no fato: ReportViewer é uma solução gratuita. Qualquer relatório mais complexo que sua empresa precise, posivelmente tenha que meter a mão no bolso.

Mas, continuando… A questão agora é o Nhibernate. Sem problemas! No seu DAO e/ou BO voce deve ter um método que retorne para a camada de apresentação os dados que prentende utilizar no relatório. Esses dados podem ser retornados de diversas formas: IList, IList<> ou o próprio DataTable, inclusive utilizando a estrutura definida no DataSet/DataTable do relatório. Não aconselho usar DataTable nas camadas BO e DAO para retornar dados. Surigo utilizar sempre IList<> nessas camadas e deixar pra conversão em DataTable na camada de apresentação utilizando algum foreach. (Já notou que eu uso C#, não é?) O DataTable destino será aquele mesmo que formatou o relatório do ReportViewer.  Associe o DataTable o relatório, preencha os campos de parâmetros e mande exibir. Vc pode seguir um dos tutoriais que indico acima.

Mas se vc não quiser utilizar o visualizador padrão do ReportViewer? Eu sempre exporto o relatório para PDF e envio  os bytes do arquivo diretamente para o STREAM de tela. No browser do cliente o Adobe Reader captura isso e abre no browser como arquivo PDF. Não há necessidade de gerar arquivo em disco como eu fazia no início.

Mas como fazer esta exportação! Vou dar duas sugestões. A primeira é aprender como se faz consultando os seguintes links: Link 1 e Link 2. A outra opção é “use o que tá pronto”. Na página de Sistemas c/ Fontes deste blog eu disponibilizo uma aplicação que faz exatamente as coisas que eu descrevi aqui. A aplicação é Contas a Pagar on-line. Nele voce pode encontrar os arquivos .rdlc criados, o DataSet com os DataTables criados e o método de exportação em PDF em funcionamento.  Há métodos para exportão para Excel e PDF, em vetor de bytes (o que possibilita o envio do resultado diretamente para o ‘stream’ de tela) ou arquivo. Fica a sua escolha. Inclusive mostra como passar parâmetros para o relatório. Esse parâmetros podem ser exibidos, por exemplo, no cabeçalho do relatório como o nome do estabelecimento ou perído. Uma dica: visite esta dica que lá mostra como exportar diretamente para PDF ou Excel sem ter que passar pelo processo de seleção no ReportViewer.

Adiquira o  projeto e veja uma aplicação prontinha utilizando esses conceitos. Além de estar investindo em seu aprendizado está contribuindo para meus estudos e pesquisas. A implementação completa dos métodos fazem parte da Regisoft Library que voce também pode adquirir.

Bom, é isso. Obrigado pela atenção e até a próxima.

Um bom começo para quem prentende trabalhar com escalabilidade é verificar se seu sistema admite a possibilidade de trabalhar utilizando um servidor de aplicação: as aplicações clientes (desktop ou web) fazem requisições a um servidor. Neste servidor estão implementados todas as regras de negócio e esse servidor faz acesso ao banco de dados para, então, responder às solicitações. Para utilizar essa proposta, que modificações voce teria que fazer no seu sistema?

1. Teria que reescrever o sistema em outra plataforma?
2. Teria que efetuar algumas mudanças sim. Voce acha que dá pra fazer? Em quanto tempo?
3. Teria que, primeiro ser treinado em ambiente em camadas pra depois pensar nisso?
4. Teria que, primeiro mudar sua forma de programar?
5. Teria que colocar as regras de negócio da aplicação em um só lugar para depois pensar no servidor de aplicação?
6. Teria que modelar o sistema primeiro em orientação a objetos?
7. Outro “teria” qualquer….

Veja que parece simples responder a esta pergunta mas não é tão imediato assim. Nem todos os sistemas são preparados para isso efetivamente. Outras respostas:

1. Construimos o sistema com esta visão. Foi previsto que o projeto teria grande possibilidade de crescimento tanto em recursos quanto em necessidades.
2. Sim. É só modificar o arquivo de configurações do sistema para que as aplicações clientes façam solicitações para o servidor.
3. Sim. Só preciso modificar uma linha do sistema, recompila-lo e recoloca-lo em produção.
4. Quantos servidores posso utilizar? Pelo menos um servidor para DAO´s e banco de dados e um outro servidor de regra. Poderiam ser mais servidores de aplicação espalhados pela rede. Depende apenas do nível de resposta que a empresa pretende ter e da disponibilidade de recursos físicos.
5. O sistema permite dividir papéis facilmente.
6. Outros “só se for agora” qualquer….

Se voce puder utilizar alguma dessas respostas, parabéns. Voce já está no caminho certo. É essa linha que a engenharia de software moderna quer que os novos sistemas sigam. Para aqueles que aindam não perseguem estes objetivos vou tentar passar algumas dicas como roteiro inicial a seguir.

Eu utilizava .NET 1.1 quando me fiz a seguinte pergunta: Em J2EE, pode-se configurar a utilização de um servidor de aplicação através dos EJB containers. JBoss é um exemplo de servidor de aplicação gratuito em Java. Pode-se também construir aplicações distribuidas com JavaRMI. E qual o servidor de aplicação para .NET e como construir aplicações distribuidas??? Há um tempo atrás fui a uma apresentação sobre .NET 2.0 com Visutal Studio 2005. Na saída fiz essa pergunta ao facilitador e ele me respondeu com uma palavra: “Remoting”. Ao chegar em casa me dediquei a pesquisar sobre o assunto. A seguir, deixo indicado um artigo que serviu de base para nossa trajetória sobre o assunto:

.NET Remoting – Parte 1 – Acessando informações remotamente
.NET Remoting – Parte 2 – Acessando informações remotamente

Desde então temos trabalhado para que a construção dos nossos sistemas tenham carateríscas que viabilizem a arquitetura de acesso remoto. As pessoas que acompanharam em nosso blog os post entitulados NHIbernate + Visual Studio: Construindo aplicações em camadas devem ter notado em algumas partes dos códigos e da explanação a presença de flags para utilização de servidor de aplicação. Desenvolvemos uma solução chamada RemoteServer.NET em Visual Studio com 3 projetos que casa perfeitamente com esses indicadores:

1. RemoteServerWin: Um servidor de aplicação utilizando .NET Remoting que roda como aplicação do windows.
2. RemoteServerService: Um servidor de aplicação, também utilizando .NET Remoting que roda como serviço do windows.
3. RemoteServerSetup: Um instalador dos projetos anteriores.

Vamos entender o esquema abaixo numa proposta didática, porém bem próxima de uma arquitetura ideal:

No ínicio do processo temos um usuário utilizando o seu computador para fazer solicitações ao servidor web através de um navegador. O servidor web é responsável apenas pela apresentação e desenho da página web. Qualquer necessidade de processamento de regras de négocio deverá ser enviada ao servidor de negócio. A linha usuario-navegador-servidor web-servidor de negócio poderia ser subistituida por outras configurações: celular-servidor web-servidor de negócio, aplicativo windows-servidor de negócio, etc. O fato é que o servidor de negócio precisa está preparado para receber e responder a requisições remotas. Neste servidor estaria configurado o RemoteServer.NET para responder solicitações da camada de apresentação. Algumas vezes o servidor de aplicação precisaria acessar dados do banco de dados. Esse acesso, de acordo com padrões de projetos e arquitetura em camadas deveria ser através de DAO´s. Logo poderiamos ter um servidor DAO para responder requisições feitas pelo servidor de negócio. Neste servidor DAO também teria instalado o RemoteServer.NET para responder requisições remotas. Por fim, temos uma máquina como servidor de banco de dados para acesso a dados.

As possibilidades são inúmeras. Imagine um enorme volume de usuários fazendo acesso ao servidor de regra. Poderiamos colocar novos servidores de negócio pra dividir a carga ou mesmo, mais servidores de acesso a dados fazendo com que as requisições fossem aleatórias a estes servidores evitanto o engarrafamento de requisições no mesmo servidor. Poderiamos também fazer replicação sincrona de dados no banco ou mesmo, utilização de cluster para dividir a carga de acesso ao banco de dados. Tudo dependendo do potencial do parque de informática da empresa e necessidade de acesso rápido ás informações. Adicionemos a tudo isso uma dose de XML Web Service para que outra aplicações possam conectar-se diretamente a seu servidor de regras via web.

As aplicações que voce desenvolve suporta essas possibilidades?  Isso é ESCALABILIDADE.

Na nossa página de Sistemas c/ Fontes estamos disponbilizando a solução RemoteServer.NET para aqueles que desejarem adquirir e ampliar seus horizontes. Vale lembrar que o RemoteServer.NET sozinho não faz milagre. A aplicação como um todo deve ser pensada para suportar esses requisitos. O primeiro passo é repensar seus conceitos em desenvolvimento e pesquisar soluções que sejam multi-utilizáveis.

Quem desejar adiquirir esse e outros produtos entre em contato. Teremos o maior prazer em responder. Voce estará contribuindo para manter nossas pesquisas bem como, a qualidade das nossas publicações.

É isso.