Olá a todos!!

Eu e minha equipe na faculdade estamos desenvolvendo o nosso TCC em Visual Studio 2005 com C# 2.0. Teremos a versão para windows e a versão web do sistema, as duas desenvolvidas na arquitetura de três camadas.

A nossa maior dúvida no momento é em questão ao ADO.NET, qual o modelo mais adequado para o deselvolvimento,o modelo conectado, ou o modelo desconectado.

Deve ser levado em consideração que o nosso sistema quando colocado em produção não deverá ter muitos acessos simultaneos, digamos que uns 10, ou no maximo 15, e que queremos reaproveitar todas as classes de acesso a dados e de regras de negocio que será feito na aplicação windows para a aplixação web.

Gostaria de saber a opinião de vocês, sobre o modelo conectado e o modelo desconectado, qual os casos de aplicação de cada um e qual seria o melhor modelo para a nossa aplicação.

Vlw moçada... Abraços.

Exibições: 809

Respostas a este tópico

Boa Tarde Arilton,
Em .Net não existe essa questão de conectado ou desconectado (Corrijam-me caso esteja errado), você sempre vai trabalhar desconectado.

Espero ter ajudado.

[]'s,
Fernando Gonçalves
Olá,

O que quer dizer trabalhar conectado?

[]'s,
Thaís
Airton,
Trabalhar sempre desconectado do banco de dados por padrão. Evitar ao máximo prender conexões com o banco de dados.
[],
Salve guerreiro ... !

Para aplicações que usam a plataforma .NET, o acesso aos dados é feito usando-se a ADO.NET. Se considerarmos que mais da metade das aplicações usam o acesso a algum banco de dados e que as informações que estas aplicações gerenciam precisam ser tratadas de forma segura, concluímos que devemos considerar cenários críticos que podem afetar a integridade dos dados em nossas aplicações.

Quando múltiplos usuários tentam efetuar uma alteração nos dados de sua aplicação ao mesmo tempo ocorre o que é conhecido por concorrência de dados.

Se você considerar que a ADO.NET elegeu como modelo principal de acesso a dados a forma desconectada (DataSets) percebe a importância de compreender bem o problema para criar mecanismos para tratá-lo de uma forma consistente. Quando ocorre o conflito de dados durante a concorrência é preciso estabelecer um controle com o objetivo de prevenir a perda de informações durante o acesso simultâneo de diversos usuários.

O controle a concorrência de dados previne que um usuário sobrescreva as modificações que outros usuários realizaram no mesmo registro da tabela. Conforme aumenta a quantidade de usuários concorrentes a uma aplicação ADO.NET 2.0 cresce a importância do controle da concorrência com o objetivo de permitir a disponibilidade e a integridade dos dados.

De forma geral existem 2 formas comuns de gerenciar a concorrência no acesso a dados:

1- A concorrência Pessimista - Todas as linhas que estão sendo modificadas são bloqueadas pelo usuário e ninguém mais pode realizar alterações até que o bloqueio (lock) seja liberado. O bloqueio evita que outros usuários efetuem a leitura ou modificação nos registros até que o primeiro usuário confirme as alterações no banco de dados (commit). Um exemplo muito comum é bloquear todos os registros filhos quando o usuário atualiza o registro pai, neste caso, pode-se estar impedindo o acesso a um grande número de linhas.

Este tipo de concorrência é usada em ambientes com uma grande contenção de dados onde a utilização do bloqueio dos registros é menos oneroso do que usar roll back nas transações e, além disto, requer uma conexão contínua com o banco de dados. (Se o bloqueio das linhas for efetuado por um tempo muito longo haverá um grande impacto negativo no desempenho da aplicação.)

Este modelo é útil para situações onde a modificação da linha durante a transação pode ser prejudicial como no caso de uma aplicação de controle de estoques onde você quer bloquear um produto até que o pedido seja gerado afim de mudar o estado do item como liberado para em seguida removê-lo do estoque. Se o pedido não for confirmado o bloqueio será liberado de forma que outros usuários poderão consultar o estoque e assim obter um valor real do disponível.

Este modelo não pode ser usado na arquitetura desconectada de dados pois neste modelo as conexões são abertas somente o tempo suficiente para ler ou atualizar os dados, assim os bloqueios não poderão se mantidos por longos períodos.

2- A concorrência Otimista - O bloqueio das linhas não é usado para a leitura dos dados, mas , somente enquanto eles estão sendo atualizados (um tempo médio entre 5 a 50 milisegundos). A aplicação verifica as atualizações feitas por outro usuário desde a sua última leitura. Se outro usuário atualizou a linha depois que o usuário atual leu a linha ocorre uma violação da concorrência e a última atualização não será confirmada.

Este tipo de concorrência é indicada para ambientes com baixa contenção de dados e é usada de forma padrão pela plataforma .NET que privilegia o acesso desconectado aos dados através do uso de DataSets .( Neste modelo de acesso aos dados o bloqueio de linhas por um período longo é impraticável.)

A arquitetura de componentes de dados desconectados requer um controle de concorrência otimista em ambientes com múltiplos usuários. Este modelo trabalhar da seguinte forma:

Os usuários recebem um conjunto de dados para exibir e editar;

Os objetos DataTable armazenam o conjunto de dados com os valores originais, os valores editados e os dados não alterados;

Conforme a atividade de edição e a latência do conjunto de dados aumenta, aumenta a probabilidade de violação de concorrência;

Quando for executada uma atualização nos dados a versão original da linha alterada é comparada com a linha existente no banco de dados;

Se as linhas forem diferentes a atualização não será efetivada gerando uma violação de concorrência. (Neste ponto para você pode efetuar a conciliação entre as linhas usando sua lógica de negócio)

Nota: Você pode diminuir a probabilidade de violação da concorrência atualizando o conjunto de dados imediatamente antes de atualizar os registros mas deve levar em consideração que este mecanismo aumenta a carga de rede e no banco de dados.

Os objetos DataAdapaters (1.1) e TableAdapter (2.0) fornecem a propriedade ContinueUpdateError que você pode definir para True para impedir que a exceção DBConcurrentcyException seja disparada quando ocorrer uma violação de concorrência durante a atualização de dados via comando Update.
Ao Eliminar estas exceções é possível efetuar múltiplas atualizações - algumas dais quais possuem a violação de concorrência - para continuar sem a intervenção do usuário. Quando uma violação ocorre , o DataAdapter define o valor da propriedade DataRow.RowError da sua DataTable fonte para algo parecido com "Concurrency violation: the UpdateCommand affected 0 of 1 records".

A estratégia em usar esta propriedade pode ser útil em um cenário onde temos somente um DataTable pois atualizar tabelas relacionadas requer a criação de 3 DataTables temporários para cada DataSet.DataTable. Definir o valor da propriedade ContinueUpdateError para True em um cenário com mais de uma tabela relacionada não é uma boa prática de programação visto que resolver o conflito de violação de concorrência para tabelas relacionadas não é uma tarefa das mais fáceis.

Então qual estratégia para controlar a concorrência de dados devemos adotar ?

A resposta é : Depende.

Antes de você começar a escrever o código para controlar a concorrência de dados você deverá definir em conjunto com seu cliente a estratégia de tratamento para as situações de concorrência de dados. Para ajudá-lo nesta tarefa temos a seguir as principais questões envolvidas nesta especificação:

- Será permitido a todos os usuários decidir se sobrescrevem as alterações feitas por outros usuários ?
- A decisão de sobrescrever alterações feitas por outros usuários estarão restritas a determinados perfis de usuários ? (Neste caso todas as tabelas deverão possuir uma coluna identificar o usuário que incluiu ou modificou a linha por último.)
- Que informação deverá ser apresentado ao usuário para que ele possa tomar a decisão de sobrescrever as alterações ? (Em muitos casos os usuários necessitam visualizar as alterações feitas nas linhas pelos demais usuários, e, isto requer um carga no servidor.)
- Serão permitidas atualizações em mais de uma entidade de dados sem salvar os dados para as entidades individuais no servidor ?
- Deverá uma única violação de concorrência impedir ou desfazer todas as mudanças associadas com a atualização ? (Desfazer todas as alterações requer uma transação do lado do cliente que não é fácil de implementar com os componentes de dados.)
- Será permitido aos usuários recuperar ou gerar novamente linhas deletadas por outros usuários ?

Após uma definição do que deve ser feito você pode decidir o que implementar mas de forma geral você ficará com as seguintes opções:

- First-win (o primeiro ganha) - A última alteração é removida. (Equivale a definir ContinueUpdateError como True)
- Last-win (o último ganha) - A última alteração é sempre aplicada.
- Ask-the-user (pergunte ao usuário) - O usuário escolhe o que fazer. (Equivale a definir ContinueUpdateError como False e implementar a lógica para exibir e conciliar as linhas em conflito)

Só falta eu falar sobre como você pode verificar e testar as violações de concorrência. Vamos lá...

Nota: Lembrando que eu estou considerando a concorrência otimista.

Existem diversas formas de testar a violação de concorrência e eu não pretendo esgotar o assunto, vamos abordar as técnicas mais usadas:

1- Usar DataSets - Os DataSets mantêm valores originais das linhas para que o Adapter possa efetuar a verificação de concorrência otimista durante a atualização do banco de dados. (Veremos isso mais adiante)

2- Copiar os dados originais - Ao manter uma cópia dos valores dos dados originais durante a recuperação de dados, você pode efetuar uma verificação dos valores atuais do banco de dados conferindo se eles equivalem com os valores originais armazenados. Se não forem equivalentes temos uma violação de concorrência.

3- Usar timeStamps - Você inclui uma coluna de timestamp em cada tabela que é sempre retornada em cada consulta feita no banco de dados. Ao ocorrer uma tentativa de atualização o valor da coluna é comparada com o valor original da linha modificada, se o valores forem iguais a atualização é executada e a coluna timestamp atualizada com data e hora atuais, caso contrário ocorreu uma violação de concorrência.

Para encerrar veremos a seguir a utilização dos datasets na concorrência otimista.

DataSet - Fornece um representação relacional em memória de dados , sendo um conjunto completo de dados que incluem tabelas que contém dados, restrições de dados e relacionamentos entre as tabelas. O acesso é desconectado.
- Quando você usa um DataSet frequentemente você também usa um DataAdapter para interagir com sua fonte de dados.
- Quando você usa um DataSet você pode empregar um DataView para aplicar ordenamento e filtragem nos dados do DataSet.
- O DataSet também pode ser herdado para criar um DataSet fortemente tipado com o objetivo de expor tabelas, linhas e colunas como propriedades de objetos fortemente tipados.

Você já sabe que os DataSets adotam o paradigma desconectado de dados, e , se você ainda não parou para pensar, este modelo trás a tona um problema que é o tratamento da violação da concorrência de dados. Imagine o seguinte cenário:

- O João preenche um DataSet com os registros de um banco de dados e efetua alterações no modo desconectado;
- Ao mesmo tempo a Maria preenche outro DataSet com os mesmo dados e esta atualizando os mesmos registros em outra aplicação;
- Como você pode determinar quais registros foram alterados quando o João tentar aplicar as alterações feitas ao banco de dados ?

RSS

© 2019   Criado por Ramon Durães.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço