O Visual Studio .NET possui muitos novos recursos, possibilitando que realizemos tarefas antes muito difíceis de serem realizadas com VB 6.0.

Vamos então fazer uma aplicação de exemplo para demonstrar alguns desses recursos. Em nossa aplicação vamos fiscalizar um determinado diretório (c:\dados, por exemplo), identificando a criação de novos arquivos neste diretório. Ao ser criado um novo arquivo, iremos ler seu conteúdo (que estará em formato XML) para um DataSet e importar seu conteúdo para uma tabela do banco.

A tabela terá a seguinte estrutura:


            Nome varchar(40)
            Cargo varchar(30)
        

Apenas para o exemplo não importa muito quantos campos iremos utilizar, isso não irá alterar a forma de construir o código.

Para começar precisaremos criar uma nova aplicação. Mas não criaremos uma WindowsApplication comum, para garantir que a aplicação possa estar sempre rodando e que possa ser iniciada de imediato quando o sistema iniciar deveremos criar a aplicação como Windows Service, ou seja, um serviço do Windows.

 Criando uma aplicação com o Windows Servic

Vamos chamar o serviço de ImportacaoDados. Além de criar o projeto com esse nome devemos alterar o ServiceName da classe Service1 que é criada para nós. Podemos Também alterar o nome da classe, name, para ImportacaoDados, por exemplo. Devemos usar a janela de propriedades, não o código, pois este nome aparece em vários locais do código de inicialização do serviço.

As propriedades da classe ImportacaoDados (que herda as características da classe ServiceBase) possui várias propriedades que determinam os eventos do sistema que o serviço pode tratar. A configuração default já é adequada, com a propriedade CanStop definida como true, indicando que o serviço trata o evento de stop, e a propriedade autolog como true, indicando que o serviço irá automaticamente logar os eventos de stop, start que ocorrerem.

Todo serviço precisa de um instalador, que é criado dentro do mesmo Assembly do serviço. Mas o VB.NET pode inserir o instalador no projeto automaticamente, basta que na janela de propriedades, com a classe ImportacaoDados selecionada, cliquemos na instrução Add Instaler, na parte inferior da janela de propriedades.

Fazendo isso será criado um novo arquivo .VB chamado ProjectInstaller.VB . Neste arquivo são criados os componentes ServiceInstaller1 e ServiceProcessInstaller1. Precisamos configurar esses dois componentes:

No ServiceInstaller1 vamos alterar o starType para Automatic. Isso determina que o serviço deverá ser configurado para se iniciar automaticamente sempre que o Windows se iniciar. É interessante observar que poderíamos também configurar as dependencias do serviço, determinando que para se iniciar o serviço precisará que outros já estejam iniciados. No nosso exemplo, porém, não precisamos configurar isso.

No ServiceProcessInstaller1 deveremos alterar a propriedade Account para LocalSystem, determinando assim que no momento de instalação o serviço deve ser configurado para rodar na LocalSystemAccount, conta local do sistema.

Componentes

Voltando ao Service1.vb, vamos inserir um componente chamado FileSystemWatcher. Este objeto nos permite fazer uma tarefa que antes era extremamente complexa: Vigiar o sistema de arquivos para identificar alterações em arquivos, deleção, criação de novos arquivos, ou outros eventos no sistema.

Vamos alterar o nome do FileSystemWatcher, chamando-o apenas de FSW. Existem 3 propriedades que determinam quais arquivos serão vigiados : Filter, determina o filtro de arquivos, configurado como "*.*" por default. Path determina o caminho da pasta que será vigiada e NotifyFilter determina os eventos que serão checados.

Em nosso exemplo iremos verificar apenas a criação de arquivos, então podemos alterar notifyFilter para Filename. Iremos também configurar o Path como "C:\dados" e manter o filter da forma que está. Um recurso interessante que devemos utilizar são as Dynamic Properties. Filter e Path são ótimos candidatos a serem configurados como Dynamic Properties. A configuração de Dynamic Properties nos permite vincular uma propriedade de um determinado objeto a uma configuração no manifesto da aplicação. Desta forma podemos manter os valores de filter e path gravados em um arquivo externo, o que fará com que estas propriedades sejam facilmente alteradas mesmo com a aplicação já compilada.

Exemplo de aplicação

Basta para isso selecionarmos na janela de propriedades o item Dynamic Properties e darmos um nome que será utilizado para a gravação das propriedades Filter e Path. Ao fazermos isso o janela de propriedades passa a sinalizar o fato das propriedades estarem sendo lidas de um arquivo de configuração, enquanto no solution explorer podemos observar que é adicionado o arquivo de configuração, inicialmente com o nome de APP.config.

A propriedade EnableRaisingEvents do FileSystemWatcher funciona como um on/off, determinando se ele estará ou não vigiando o sistema de arquivos e disparando eventos para nos alertar do ocorrido.

Como estamos desenvolvendo um serviço, vamos inicialmente configurar a EnableRaisingEvents como False e vamos habilita-la/desabilita-la no start/stop do serviço. Para isso basta entrarmos no código do service1.vb e começarmos o desenvolvimento, veja:


            Protected Overrides Sub OnStart(ByVal args() As String)
' Add code here to start your service. This method should set things
' in motion so your service can do its work.
FSW.EnableRaisingEvents = True
End Sub

Protected Overrides Sub OnStop()
' Add code here to perform any tear-down necessary to stop your service.
FSW.EnableRaisingEvents = False
End Sub
        

No Service1.vb, deveremos criar um objeto OledbConnection e um objeto OledbCommand que servirão para fazermos a conexão com o banco de dados e atualizarmos os dados no banco. Vamos chama-los de CN e CMD, para ficar mais fácil trabalhar com eles. Precisaremos definir a string de conexão no objeto CN. A string de conexão é outra excelente candidata a se transformar em Dynamic Properties, não apenas neste exemplo mas eu diria que em toda aplicação, desta forma permitindo que a localização do banco de dados possa ser facilmente alterada, apenas corrigindo a string dentro do manifesto da aplicação.

Já no objeto CMD vamos liga-lo com o objeto CN e definir o commandText. Podemos montar o CommandText dinâmicamente através do query Builder, basta termos o cuidado de alterar o tipo da query para insert into e utilizarmos ? nos valores que deverão ser preenchidos por parâmetros.

Aplicação

O objeto OLEDBCOMMAND sempre pergunta, após a montagem da query, se podem redefinir a coleção de parâmetros do Command. Devemos permitir e ele irá criar a definição dos parâmetros nome e cargo para nós. Podemos ver o que foi feito através da coleção parameters, mas não iremos alterar nada.

Chegou a hora então de programarmos o evento Created do FSW, que é disparado sempre que um novo arquivo é criado no diretório que está sendo vigiado. Nosso objetivo é criar um DataSet e carregar para dentro do DataSet os dados do novo arquivo. Veja como fica o inicio deste código:


            Private Sub FSW_Created(ByVal sender As Object, ByVal e As

System.IO.FileSystemEventArgs) Handles FSW.Created

 

Dim ds As New DataSet()

 

ds.ReadXml(e.FullPath)

 

End Sub
        

Assim, com apenas duas linhas de código carregamos para um DataSet o conteúdo do novo arquivo. Agora precisamos atualizar o banco. Isso exigiria normalmente que fizessemos um algorítimo como loop para jogarmos os dados no banco executando o Command. Bem, não no .NET. Podemos apenas criar um DataAdapter, liga-lo ao Command e utiliza-lo para atualizar o banco automaticamente. Veja como fica o código:


            Private Sub FSW_Created(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Handles FSW.Created

Dim ds As New DataSet()
Dim da As OleDb.OleDbDataAdapter

 

ds.ReadXml(e.FullPath)

 

da = New OleDb.OleDbDataAdapter()
da.InsertCommand = cmd

 

da.Update(ds, "funcionario")


ds.Dispose()
ds = Nothing
da.Dispose()
da = Nothing
End Sub
        

Observem que este data adapter nem ao menos possui um selectCommand. Isso não é necessário já que estamos apenas inserindo registros no banco.

Pronto. Está feito. Isso mesmo. Com Poquissimas linhas de código, praticamente um desenvolvimento todo visual, conseguimos montar uma aplicação que será instalada como serviço do Windows, monitorar os arquivos criados em um diretório, ler o conteúdo destes arquivos e jogar os dados para uma tabela de banco.

O próximo passo é instalar esse serviço. Para isso o framework nos traz um utilitário chamado installutil. Executando no prompt InstallUtil este utilitário dispara o instalador que criamos em nosso assembly e o instalador por sua vez se encarrega de fazer as configurações do serviço na máquina.

Você agora só precisa agora ter cuidado com a montagem do arquivo XML, pois o dataSet é um pouco temperamental na leitura deste arquivo. Veja um exemplo de como ele fica:


            <cadfunc>
<funcionario>
<nome>Joao</nome>
<cargo>faxineiro</cargo>
</funcionario>
</cadfunc>
        

Observe a forma como os dados estão montados : Nome e cargo estão colados a suas respectivas tags. Veja um exemplo do que sereia uma montagem ERRADA:


            <cadfunc>
<funcionario>
<nome>
Joao
</nome>
<cargo>
faxineiro
</cargo>
</funcionario>
</cadfunc>
        

Você pode pensar a principio que não existe nada errado neste XML e, realmente, ele é um XML válido. Mas se olhar mais atentamente poderá observar que dentro do campo nome e dentro do campo cargo temos 2 CR (Enter, código ASC=13). Isso será lido como parte dos dados e inserido como informação nestes campos, dentro do banco de dados. Desta forma devemos tomar cuidado com o que inserimos nas tags de dados do XML.

Tendo esse cuidado, você poderá montar vários arquivos e joga-los, um por um, no diretório que está sendo vigiado por sua aplicação. Poderá observar como a aplicação lê o conteúdo do XML e executa o insert na base de dados.