Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«

Palm ou pão
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Cache vinculado ao banco no ASP.NET

Pesquisa personalizada
Pesquisar Dicas:







Frequentemente, durante o uso de um site, os usuários acessam os mesmos conjuntos de dados, solicitando sempre as mesmas informações. Para otimizar situações como estas utilizamos o sistema de cache do ASP.NET para manter dados na memória do servidor web.

O sistema de cache do ASP.NET nos permite fazer vínculos dos dados em cache com um arquivo em disco.

E para que estes vinculos ?

Para garantir a atualização dos dados. Os dados em cache são em geral dataSets. Então podemos ter no disco estes mesmos datasets em formato XML, como origem destes dados. Fazendo o vinculo podemos garantir que assim que os dados forem alterados, aparecerão alterados na web, pois o ASP.NET se encarregará de destruir os dados do cache.

Veja um exemplo :

  106     Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

  107 

  108 

  109         'Put user code to initialize the page here

  110         If Not Page.IsPostBack Then

  111             CarregarGrid()

  112         End If

  113     End Sub

  114     Sub CarregarGrid()

  115         If IsNothing(Cache("produtos")) Then

  116             DsProdutos1.ReadXml("C:\testecache\produtos.xml")

  117             Cache.Insert("produtos", DsProdutos1, New Caching.CacheDependency("C:\testecache\produtos.xml"))

  118 

  119 

  120         End If

  121         DG.DataSource = Cache("produtos")

  122         DG.DataBind()

  123     End Sub

  124 

  125     Private Sub DG_PageIndexChanged(ByVal source As Object, ByVal e As System.Web.UI.WebControls.DataGridPageChangedEventArgs) Handles DG.PageIndexChanged

  126 

  127 

  128         DG.CurrentPageIndex = e.NewPageIndex

  129         CarregarGrid()

  130     End Sub

Porém, neste exemplo, temos o vínculo entre os dados que encontram-se no XML e o cache do ASP.NET, mas não temos um vínculo direto com a base de dados. O ASP.NET não suporta um vinculo direto com a base de dados, mas podemos contornar isso facilmente.

Para contornar isso podemos criar triggers na tabela do banco de dados. Esses triggers, ao identificarem alterações nos dados, podem re-gerar o arquivo XML. Ao ser re-gerado o arquivo XML provocará a destruição do cache em memória e os dados serão re-carregados.

Porém isso é um trabalho que só de ouvirmos já assusta : Fazer triggers que gerem arquivo XML não parece ser uma tarefa simples.

Mas o que muitos não sabem é que desde a versão 7.0 o SQL Server possui um Wizard que faz isso para nós automaticamente. Trata-se do Web Assistant Wizard.

No SQL Server 7 esse wizard podia ser encontrado em Management, no enterprise manager. No sql server 2000 ele foi um pouco mais oculto. Provavelmente porque inicialmente a finalidade dele era gerar sites estáticos em HTML - algo pouco usado hoje em dia. Porém esse wizard pode, como veremos, gerar o código XML de um dataSet, sem dificuldade, permitindo assim a integração entre a base de dados e o cache do ASP.NET.

Então vamos fazer um passo-a-passo para a geração do arquivo XML a partir do SQL Server, integrando assim com o cache do ASP.NET.

Primeiramente precisamos de um arquivo XML exatamente no formato que desejamos gerar. O WriteXML de um dataSet pode gerar esse arquivo XML para nós.

A partir do arquivo XML gerado por um WriteXML, vamos criar um modelo que o SQL Server usará para gerar os dados no formato XML. O modelo terá apenas um registro e precisará incluir tags especiais que serão reconhecidas pelo SQL Server.

Precisamos marcar as tags do registro - que precisarão ser repetidas para cada registro do banco - com as tags <%begindetail%> e <%enddetail%> . Dentro do registro, em cada campo, deveremos inserir a tag <%insert_data_here%> no local em que desejamos que o valor do campo apareça. Observe que não existe especificação de nome do campo, os campos deverão estar na ordem correta.

Agora que criamos o modelo vamos iniciar o Wizard. No SQL Server 2000 ele se localiza em Tools, Wizards. É necessário abrir o item Management e encontraremos, como último da lista, o Web Assistant Wizard.

Na primeira tela o Wizard nos pergunta qual banco de dados desejamos utilizar. Em nosso exemplo vamos selecionar o northWind.

Em seguida ele nos pergunta como desejamos obter os dados. As opções são 3 :

Vamos selecionar a 1a opção

Na tela seguinte escolhemos a tabela e os campos que serão gerados para o XML. Escolheremos a tabela products, com todos os campos.

Na tela seguinte é oferecida a opção de filtrarmos os dados que serão gerados para o XML. Vamos selecionar a opção de que desejamos todos os dados, sem filtro.

Agora precisamos decidir quando o XML será gerado. Para termos o efeito desejado precisamos escolher a opção "When the SQL Server data changes". Essa opção fará este wizard criar os triggers conforme indicarmos. Vamos tambem deixar a checkbox que fica mais abaixo marcada. Ela indica que o wizard deverá, ao final do wizard, gerar o XML pela primeira vez.

Na tela seguinte o wizard nos pergunta quais tabelas e campos devem ser monitorados pelo trigger para disparar a geração do XML. Normalmente a escolha é a mesma que fizemos anteriormente, quando selecionamos os dados do XML, raramente mudará.

O Wizard nos pergunta onde salvar o arquivo, indique um local e tome o cuidado de indicar a extensão XML

Agora o wizard se oferece para fornecer um auxilio para a formatação da página. Isso porque, como citei, o objetivo inicial do wizard era criar sites estáticos. Porém esta formatação não serve para nós, que estamos criando XML. Então selecionamos a opção para fornecer um modelo e indicamos onde está o nosso modelo.

Na tela seguinte o wizard nos pergunta se desejamos fazer algum tipo de paginação ou limitação na quantidade de registros que será retornada. Outra coisa que não serve para nosso caso, que desejamos um XML completo para o cache do ASP.NET.

Por fim basta utiliza finish e teremos um arquivo XML já gerado com base em nosso modelo e serão criados na tabela os triggers para geração deste arquivo XML.

Com isso, sempre que os dados forem alterados na base de dados o arquivo XML será re-gerado. Como o ASP.NET está vigiando este arquivo, irá imediatamente destruir o cache na memória do servidor web. Destruido o cache, nosso código da aplicação perceberá e recarregará os dados. Simples assim : Alterou no banco, apareceu na aplicação, mesmo com o cache.

Observações finais

Esse cenário, quando aplicado em produção, requer que o servidor de banco faça uma gravação no servidor web. Isso requer configurações no servidor de banco que deverão ser feitas pelo DBA

No Framework 2.0 surgiu o conceito de SQLCacheDependency, para fazer o vínculo de cache entre o ASP.NET e o banco de dados. Mas não se iludam, não há mágica, é preciso analisar cuidadosamente tudo que estará sendo feito. Quando o SQLCacheDepencency é aplicado no SQL Server 7 ou 2000 o ASP.NET cria um timer e passa a consultar o banco conforme este timer, verificando se houve variação dos dados. Isso onera consideravelmente a rede e o banco. Portanto, essa solução que apresentei acima e que é perfeitamente viável com o .NET 1.1 e SQL Server 2000, é melhor que o SQLCacheDependency do .NET 2.0 quando aplicado sobre bancos SQL Server 7.0 e 2000

Já quando o SQLCacheDependency é aplicado sobre bancos SQL Server 2005, é feito uso de um novo recurso do SQL Server 2005 chamado Service Broker para que o servidor SQL Server 2005 possa avisar o client quando houverem alterações nos dados. É bem mais complexo de implementar do que isso que demonstrei, mas certamente é mais escalável e, dependendo do ambiente, isso pode fazer diferença.

 



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : disney E-Mail : disney_hammer@msn.com
Olá, gostei do seu artigo e tenho uma sugestão. Seria possível colocar um modelo do template xml nele?

Grato e obrigado.

Disney
Nome : Caique Doruado E-Mail : ckdourado@gmail.com
Essa solução é válida. Porém, somente quando a aplicação e o banco de dados estão no hospedados mesmo servidor (o que dificilmente acontece e que também não é uma boa prática).

Se for possível, é melhor usar o ServiceBroker.
Abraço!
Caique Dourado