Encapsulando modificações de banco de dados em uma transação (C#)

por Scott Mitchell

Descarregar PDF

Este tutorial é o primeiro de quatro que analisa a atualização, exclusão e inserção de lotes de dados. Neste tutorial, aprendemos como as transações de banco de dados permitem que modificações em lote sejam realizadas como uma operação atômica, o que garante que todas as etapas sejam bem-sucedidas ou todas as etapas falhem.

Introdução

Como vimos começando com o tutorial Uma visão geral da inserção, atualização e exclusão de dados , o GridView fornece suporte interno para edição e exclusão em nível de linha. Com alguns cliques do mouse é possível criar uma interface de modificação de dados rica sem escrever uma linha de código, desde que você esteja contente com a edição e exclusão por linha. No entanto, em certos cenários, isso é insuficiente e precisamos fornecer aos usuários a capacidade de editar ou excluir um lote de registros.

Por exemplo, a maioria dos clientes de e-mail baseados na Web usa uma grade para listar cada mensagem onde cada linha inclui uma caixa de seleção junto com as informações do e-mail (assunto, remetente e assim por diante). Essa interface permite que o usuário exclua várias mensagens verificando-as e clicando no botão Excluir mensagens selecionadas. Uma interface de edição em lote é ideal em situações em que os usuários geralmente editam muitos registros diferentes. Em vez de forçar o usuário a clicar em Editar, fazer a alteração e, em seguida, clicar em Atualizar para cada registro que precisa ser modificado, uma interface de edição em lote renderiza cada linha com sua interface de edição. O usuário pode modificar rapidamente o conjunto de linhas que precisam ser alteradas e, em seguida, salvar essas alterações clicando em um botão Atualizar tudo. Neste conjunto de tutoriais, examinaremos como criar interfaces para inserir, editar e excluir lotes de dados.

Ao executar operações em lote, é importante determinar se deve ser possível que algumas das operações no lote sejam bem-sucedidas enquanto outras falham. Considere uma interface de exclusão em lote - o que deve acontecer se o primeiro registro selecionado for excluído com êxito, mas o segundo falhar, digamos, devido a uma violação de restrição de chave estrangeira? A exclusão do primeiro registro deve ser revertida ou é aceitável que o primeiro registro permaneça excluído?

Se você quiser que a operação em lote seja tratada como uma operação atômica, em que todas as etapas sejam bem-sucedidas ou todas as etapas falhem, a Camada de Acesso a Dados precisa ser aumentada para incluir suporte para transações de banco de dados. As transações de bases de dados garantem a atomicidade para o conjunto de INSERT, UPDATE, e DELETE instruções executadas sob a abrangência da transação e são um recurso suportado pela maioria dos sistemas modernos de bases de dados.

Neste tutorial, veremos como estender a DAL para usar transações de banco de dados. Os tutoriais subsequentes examinarão a implementação de páginas da Web para inserção em lote, atualização e exclusão de interfaces. Vamos começar!

Observação

Ao modificar dados em uma transação em lote, a atomicidade nem sempre é necessária. Em alguns cenários, pode ser aceitável que algumas modificações de dados sejam bem-sucedidas e outras no mesmo lote falhem, como ao excluir um conjunto de e-mails de um cliente de e-mail baseado na Web. Se houver um erro de banco de dados no meio do processo de exclusão, provavelmente é aceitável que os registros processados sem erro permaneçam excluídos. Nesses casos, a DAL não precisa ser modificada para suportar transações de banco de dados. No entanto, existem outros cenários de operação em lote em que a atomicidade é vital. Quando um cliente transfere os seus fundos de uma conta bancária para outra, devem ser realizadas duas operações: os fundos devem ser deduzidos da primeira conta e depois adicionados à segunda. Embora o banco possa não se importar que o primeiro passo seja bem-sucedido, mas o segundo passo falhe, os seus clientes ficariam, compreensivelmente, chateados. Eu encorajo você a trabalhar neste tutorial e implementar os aprimoramentos no DAL para suportar transações de banco de dados, mesmo que você não planeje usá-los na inserção em lote, atualização e exclusão de interfaces que criaremos nos três tutoriais a seguir.

Uma visão geral das transações

A maioria dos bancos de dados inclui suporte para transações, que permitem que vários comandos de banco de dados sejam agrupados em uma única unidade lógica de trabalho. Os comandos de banco de dados que compõem uma transação são garantidos como atômicos, o que significa que todos os comandos falharão ou todos serão bem-sucedidos.

Em geral, as transações são implementadas por meio de instruções SQL usando o seguinte padrão:

1. Indique o início de uma transação.
2. Execute as instruções SQL que compõem a transação.
3. Se houver um erro em uma das instruções da Etapa 2, reverta a transação.
4. Se todas as instruções da Etapa 2 forem concluídas sem erros, confirme a transação.

As instruções SQL usadas para criar, confirmar e reverter a transação podem ser inseridas manualmente ao escrever scripts SQL ou criar procedimentos armazenados, ou por meio de meios programáticos usando ADO.NET ou as classes no System.Transactions namespace. Neste tutorial, examinaremos apenas o gerenciamento de transações usando ADO.NET. Em um tutorial futuro, veremos como usar procedimentos armazenados na Camada de Acesso a Dados, momento em que exploraremos as instruções SQL para criar, reverter e confirmar transações.

Observação

A TransactionScope classe no System.Transactions namespace permite que os desenvolvedores encapsulam programaticamente uma série de instruções dentro do escopo de uma transação e inclui suporte para transações complexas que envolvem várias fontes, como dois bancos de dados diferentes ou até mesmo tipos heterogêneos de armazenamentos de dados, como um banco de dados Microsoft SQL Server, um banco de dados Oracle e um serviço Web. Eu decidi usar transações ADO.NET para este tutorial em vez da classe TransactionScope porque ADO.NET é mais específico para transações de banco de dados e, em muitos casos, consome muito menos recursos. Além disso, em determinados cenários, a TransactionScope classe usa o Microsoft Distributed Transaction Coordinator (MSDTC). Os problemas de configuração, implementação e desempenho em torno do MSDTC o tornam um tópico bastante especializado e avançado e além do escopo desses tutoriais.

Ao trabalhar com o provedor SqlClient em ADO.NET, as transações são iniciadas por meio de uma chamada para o método s SqlConnectionde BeginTransaction classe, que retorna um SqlTransaction objeto. As declarações de modificação de dados que compõem a transação são colocadas dentro de um try...catch bloco. Se ocorrer um erro numa instrução no bloco , a execução será transferida para o bloco , onde a transação pode ser revertida através do método do objeto . Se todas as instruções forem concluídas com êxito, uma chamada para o SqlTransaction do Commit objeto no final do bloco confirmará a transação. O trecho de código a seguir ilustra esse padrão. Consulte Mantendo a consistência do banco de dados com transações.

// Create the SqlTransaction object
SqlTransaction myTransaction = SqlConnectionObject.BeginTransaction();
try
{
    /*
     * ... Perform the database transaction�s data modification statements...
     */
    // If we reach here, no errors, so commit the transaction
    myTransaction.Commit();
}
catch
{
    // If we reach here, there was an error, so rollback the transaction
    myTransaction.Rollback();
    throw;
}

Por padrão, os TableAdapters em um DataSet tipado não usam transações. Para fornecer suporte para transações, precisamos aumentar as classes TableAdapter para incluir métodos adicionais que usam o padrão acima para executar uma série de instruções de modificação de dados dentro do escopo de uma transação. Na Etapa 2, veremos como usar classes parciais para adicionar esses métodos.

Etapa 1: Criação das Páginas da Web de Trabalho com Dados em Lote

Antes de começarmos a explorar como aumentar o DAL para suportar transações de banco de dados, vamos primeiro reservar um momento para criar as ASP.NET páginas da Web que precisaremos para este tutorial e as três que se seguem. Comece adicionando uma nova pasta chamada BatchData e, em seguida, adicione as seguintes páginas ASP.NET, associando cada página à Site.master página mestra.

• Default.aspx
• Transactions.aspx
• BatchUpdate.aspx
• BatchDelete.aspx
• BatchInsert.aspx

Figura 1: Adicionar as páginas de ASP.NET para os tutoriais do SqlDataSource-Related

Tal como acontece com as outras pastas, Default.aspx usará o SectionLevelTutorialListing.ascx Controle de Usuário para listar os tutoriais dentro de sua seção. Portanto, adicione este Controlo do Utilizador a Default.aspx arrastando-o do Gerenciador de Soluções para a vista de Design da página.

Figura 2: Adicionar o controle de usuário a SectionLevelTutorialListing.ascx (Default.aspx imagem em tamanho real)

Por último, adicione estas quatro páginas como entradas ao Web.sitemap ficheiro. Especificamente, adicione a seguinte marcação após o Customizing the Site Map <siteMapNode>:

<siteMapNode title="Working with Batched Data" 
    url="~/BatchData/Default.aspx" 
    description="Learn how to perform batch operations as opposed to 
                 per-row operations.">
    
    <siteMapNode title="Adding Support for Transactions" 
        url="~/BatchData/Transactions.aspx" 
        description="See how to extend the Data Access Layer to support 
                     database transactions." />
    <siteMapNode title="Batch Updating" 
        url="~/BatchData/BatchUpdate.aspx" 
        description="Build a batch updating interface, where each row in a 
                      GridView is editable." />
    <siteMapNode title="Batch Deleting" 
        url="~/BatchData/BatchDelete.aspx" 
        description="Explore how to create an interface for batch deleting 
                     by adding a CheckBox to each GridView row." />
    <siteMapNode title="Batch Inserting" 
        url="~/BatchData/BatchInsert.aspx" 
        description="Examine the steps needed to create a batch inserting 
                     interface, where multiple records can be created at the 
                     click of a button." />
</siteMapNode>

Após a atualização Web.sitemap, reserve um momento para visualizar o site de tutoriais através de um navegador. O menu à esquerda agora inclui itens para os tutoriais de trabalho com dados em lote.

Figura 3: O mapa do site agora inclui entradas para os tutoriais de trabalho com dados em lote

Etapa 2: Atualizando a camada de acesso a dados para dar suporte a transações de banco de dados

Como discutimos no primeiro tutorial, Criando uma camada de acesso a dados, o DataSet tipado em nossa DAL é composto por DataTables e TableAdapters. As DataTables armazenam dados enquanto os TableAdapters fornecem a funcionalidade para ler dados do banco de dados para as DataTables, para atualizar o banco de dados com alterações feitas nas DataTables e assim por diante. Lembre-se de que os TableAdapters fornecem dois padrões para atualizar dados, que eu chamei de Atualização em Lote e DB-Direct. No padrão Batch Update, o TableAdapter recebe um DataSet, DataTable ou uma coleção de DataRows. Esses dados são enumerados e, para cada linha inserida, modificada ou excluída, o InsertCommand, UpdateCommandou DeleteCommand é executado. Com o padrão DB-Direct, são passados ao TableAdapter os valores das colunas necessárias para inserir, atualizar ou excluir um único registo. Em seguida, o método DB Direct pattern usa esses valores passados para executar a instrução apropriada InsertCommand, UpdateCommand ou DeleteCommand.

Independentemente do padrão de atualização usado, os métodos gerados automaticamente TableAdapters não usam transações. Por padrão, cada inserção, atualização ou exclusão realizada pelo TableAdapter é tratada como uma única operação discreta. Por exemplo, imagine que o padrão DB-Direct é usado por algum código na BLL para inserir dez registros no banco de dados. Esse código chamaria o método TableAdapter s Insert dez vezes. Se as cinco primeiras inserções forem bem-sucedidas, mas a sexta resultar em uma exceção, os cinco primeiros registros inseridos permanecerão no banco de dados. Da mesma forma, se o padrão de atualização em lote for usado para executar inserções, atualizações e exclusões para as linhas inseridas, modificadas e excluídas em uma DataTable, se as primeiras várias modificações forem bem-sucedidas, mas uma posterior encontrar um erro, as modificações anteriores concluídas permanecerão no banco de dados.

Em certos cenários, queremos garantir a atomicidade através de uma série de modificações. Para fazer isso, devemos estender manualmente o TableAdapter adicionando novos métodos que executam o InsertCommand, UpdateCommand, e DeleteCommand sob a cobertura de uma transação. Em Creating a Data Access Layer , examinamos o uso de classes parciais para estender a funcionalidade das DataTables dentro do DataSet Typed. Esta técnica também pode ser usada com TableAdapters.

O DataSet Northwind.xsd tipado App_Code está localizado na subpasta s da DAL pasta. Crie uma subpasta na pasta DAL nomeada TransactionSupport e adicione um novo ficheiro de classe chamado ProductsTableAdapter.TransactionSupport.cs (consulte Figura 4). Este arquivo conterá a implementação parcial do ProductsTableAdapter que inclui métodos para executar modificações de dados usando uma transação.

Figura 4: Adicionar uma pasta nomeada TransactionSupport e um arquivo de classe chamado ProductsTableAdapter.TransactionSupport.cs

Insira o seguinte código no ProductsTableAdapter.TransactionSupport.cs arquivo:

using System;
using System.Data;
using System.Data.SqlClient;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
namespace NorthwindTableAdapters
{
    public partial class ProductsTableAdapter
    {
        private SqlTransaction _transaction;
        private SqlTransaction Transaction
        {
            get
            {                
                return this._transaction;
            }
            set
            {
                this._transaction = value;
            }
        }
        public void BeginTransaction()
        {
            // Open the connection, if needed
            if (this.Connection.State != ConnectionState.Open)
                this.Connection.Open();
            // Create the transaction and assign it to the Transaction property
            this.Transaction = this.Connection.BeginTransaction();
            // Attach the transaction to the Adapters
            foreach (SqlCommand command in this.CommandCollection)
            {
                command.Transaction = this.Transaction;
            }
            this.Adapter.InsertCommand.Transaction = this.Transaction;
            this.Adapter.UpdateCommand.Transaction = this.Transaction;
            this.Adapter.DeleteCommand.Transaction = this.Transaction;
        }
        public void CommitTransaction()
        {
            // Commit the transaction
            this.Transaction.Commit();
            // Close the connection
            this.Connection.Close();
        }
        public void RollbackTransaction()
        {
            // Rollback the transaction
            this.Transaction.Rollback();
            // Close the connection
            this.Connection.Close();
        }
   }
}

A partial palavra-chave na declaração de classe aqui indica ao compilador que os membros adicionados dentro devem ser adicionados à ProductsTableAdapter classe no NorthwindTableAdapters namespace. Note a instrução using System.Data.SqlClient no topo do arquivo. Como o TableAdapter foi configurado para usar o provedor SqlClient, internamente ele usa um SqlDataAdapter objeto para emitir seus comandos para o banco de dados. Consequentemente, precisamos usar a SqlTransaction classe para iniciar a transação e, em seguida, confirmá-la ou revertê-la. Se você estiver usando um armazenamento de dados diferente do Microsoft SQL Server, precisará usar o provedor apropriado.

Esses métodos fornecem os blocos de construção necessários para iniciar, reverter e confirmar uma transação. Eles são marcados public, permitindo que sejam usados de dentro do ProductsTableAdapter, de outra classe no DAL, ou de outra camada na arquitetura, como o BLL. BeginTransaction abre os componentes internos do TableAdapter (SqlConnection, se necessário), inicia a transação e atribui-a à propriedade Transaction, anexando a transação aos objetos SqlDataAdapter internos do SqlCommand. CommitTransaction e RollbackTransaction chamam os métodos do objeto Transaction e Commit, respetivamente, antes de fechar o objeto interno Rollback.

Etapa 3: Adicionando métodos para atualizar e excluir dados sob o guarda-chuva de uma transação

Com esses métodos concluídos, estamos prontos para adicionar métodos ao ProductsDataTable ou à BLL que executam uma série de comandos no contexto de uma transação. O método a seguir usa o padrão Batch Update para atualizar uma ProductsDataTable instância usando uma transação. Ele inicia uma transação chamando o BeginTransaction método e, em seguida, usa um try...catch bloco para emitir as instruções de modificação de dados. Se a chamada para o método do objeto Adapter resultar numa exceção, a execução será transferida para o bloco Update onde a transação será anulada e a exceção relançada. Lembre-se de que o método Update implementa o padrão Batch Update ao enumerar as linhas do ProductsDataTable fornecido e ao executar os InsertCommand, UpdateCommand e DeleteCommand necessários. Se qualquer um desses comandos resultar em um erro, a transação será revertida, desfazendo as modificações anteriores feitas durante o tempo de vida da transação. Se a Update declaração for concluída sem erros, a transação será consumada na sua totalidade.

public int UpdateWithTransaction(Northwind.ProductsDataTable dataTable)
{
    this.BeginTransaction();
    try
    {
        // Perform the update on the DataTable
        int returnValue = this.Adapter.Update(dataTable);
        // If we reach here, no errors, so commit the transaction
        this.CommitTransaction();
        return returnValue;
    }
    catch
    {
        // If we reach here, there was an error, so rollback the transaction
        this.RollbackTransaction();
        throw;
    }
}

Adicione o método UpdateWithTransaction à classe ProductsTableAdapter através da classe parcial em ProductsTableAdapter.TransactionSupport.cs. Como alternativa, esse método pode ser adicionado à classe s ProductsBLL da Business Logic Layer com algumas pequenas alterações sintáticas. Ou seja, a palavra-chave "this" em this.BeginTransaction(), this.CommitTransaction() e this.RollbackTransaction() precisaria ser substituída por Adapter (lembre-se que Adapter é o nome de uma propriedade em ProductsBLL do tipo ProductsTableAdapter).

O UpdateWithTransaction método usa o padrão Batch Update, mas uma série de chamadas de DB-Direct também pode ser usada no escopo de uma transação, como mostra o método a seguir. O método DeleteProductsWithTransaction aceita como entrada um List<T> do tipo int, que são os ProductID a eliminar. O método inicia a transação por meio de uma chamada para BeginTransaction e, em seguida, no bloco try, itera pela lista fornecida chamando o método padrão Delete DB-Direct para cada valor de ProductID. Se qualquer uma das chamadas a Delete falhar, o controlo será transferido para catch bloco onde a transação será revertida e a exceção será relançada. Se todas as chamadas a Delete forem bem-sucedidas, a transação será comprometida. Adicione este método à ProductsBLL classe.

public void DeleteProductsWithTransaction
    (System.Collections.Generic.List<int> productIDs)
{
    // Start the transaction
    Adapter.BeginTransaction();
    try
    {
        // Delete each product specified in the list
        foreach (int productID in productIDs)
        {
            Adapter.Delete(productID);
        }
        // Commit the transaction
        Adapter.CommitTransaction();
    }
    catch
    {
        // There was an error - rollback the transaction
        Adapter.RollbackTransaction();
        throw;
    }
}

Aplicando transações em vários TableAdapters

O código relacionado à transação examinado neste tutorial permite que várias instruções contra o ProductsTableAdapter sejam tratadas como uma operação atômica. Mas e se várias modificações em diferentes tabelas de banco de dados precisarem ser executadas atomicamente? Por exemplo, ao excluir uma categoria, podemos primeiro querer reatribuir seus produtos atuais a alguma outra categoria. Essas duas etapas reatribuindo os produtos e excluindo a categoria devem ser executadas como uma operação atômica. Mas o ProductsTableAdapter inclui apenas métodos para modificar a Products tabela e o CategoriesTableAdapter inclui apenas métodos para modificar a Categories tabela. Então, como uma transação pode abranger ambos os TableAdapters?

Uma opção é adicionar um método ao CategoriesTableAdapter nomeado DeleteCategoryAndReassignProducts(categoryIDtoDelete, reassignToCategoryID) e fazer com que esse método chame um procedimento armazenado que tanto reatribui os produtos quanto exclui a categoria dentro do escopo de uma transação definida no procedimento armazenado. Veremos como iniciar, confirmar e reverter transações em procedimentos armazenados em um tutorial futuro.

Outra opção é criar uma classe auxiliar na DAL que contém o DeleteCategoryAndReassignProducts(categoryIDtoDelete, reassignToCategoryID) método. Esse método criaria uma instância do CategoriesTableAdapter e o ProductsTableAdapter e, em seguida, definir essas duas propriedades TableAdapters Connection para a mesma SqlConnection instância. Nesse ponto, qualquer um dos dois TableAdapters iniciaria a transação com uma chamada para BeginTransaction. Os métodos TableAdapters para reatribuir os produtos e excluir a categoria seriam invocados em um try...catch bloco com a transação confirmada ou revertida, conforme necessário.

Etapa 4: Adicionando oUpdateWithTransactionmétodo à camada de lógica de negócios

Na etapa 3, adicionamos um UpdateWithTransaction método ao ProductsTableAdapter no DAL. Devemos adicionar um método correspondente à BLL. Embora a Camada de Apresentação possa chamar diretamente a DAL para invocar o UpdateWithTransaction método, esses tutoriais se esforçaram para definir uma arquitetura em camadas que isola a DAL da Camada de Apresentação. Por conseguinte, cabe-nos prosseguir esta abordagem.

Abra o ficheiro de classe ProductsBLL e adicione um método chamado UpdateWithTransaction que simplesmente chama o método DAL correspondente. Agora deve haver dois novos métodos em ProductsBLL: UpdateWithTransaction, que você acabou de adicionar, e DeleteProductsWithTransaction, que foi adicionado na Etapa 3.

public int UpdateWithTransaction(Northwind.ProductsDataTable products)
{
    return Adapter.UpdateWithTransaction(products);
}
public void DeleteProductsWithTransaction
    (System.Collections.Generic.List<int> productIDs)
{
    // Start the transaction
    Adapter.BeginTransaction();
    try
    {
        // Delete each product specified in the list
        foreach (int productID in productIDs)
            Adapter.Delete(productID);
        // Commit the transaction
        Adapter.CommitTransaction();
    }
    catch
    {
        // There was an error - rollback the transaction
        Adapter.RollbackTransaction();
        throw;
    }
}

Observação

Esses métodos não incluem o DataObjectMethodAttribute atributo atribuído à maioria dos outros métodos na ProductsBLL classe porque invocaremos diretamente esses métodos a partir das classes code-behind das páginas ASP.NET. Lembre-se de que DataObjectMethodAttribute é usado para sinalizar quais métodos devem aparecer no assistente Configurar Fonte de Dados de ObjectDataSource e em qual guia (SELECT, UPDATE, INSERT ou DELETE). Como o GridView não tem suporte interno para edição ou exclusão em lote, teremos que invocar esses métodos programaticamente em vez de usar a abordagem declarativa livre de código.

Etapa 5: Atualizando atomicamente os dados do banco de dados da camada de apresentação

Para ilustrar o efeito que a transação tem ao atualizar um lote de registros, vamos criar uma interface de utilizador que lista todos os produtos num GridView e inclui um controle Button da Web que, ao ser clicado, reatribui os valores dos produtos CategoryID. Em particular, a reatribuição de categoria progredirá de modo que os primeiros produtos recebam um valor válido CategoryID , enquanto outros recebem propositalmente um valor inexistente CategoryID . Se tentarmos atualizar o banco de dados com um produto que CategoryID não corresponda a uma categoria existente s CategoryID, ocorrerá uma violação de restrição de chave estrangeira e uma exceção será gerada. O que veremos neste exemplo é que, ao usar uma transação, a exceção gerada pela violação de restrição de chave estrangeira fará com que as alterações válidas CategoryID anteriores sejam revertidas. Quando não estiver usando uma transação, no entanto, as modificações nas categorias iniciais permanecerão.

Comece por abrir a página Transactions.aspx na pasta BatchData e arraste um GridView do Toolbox para o Designer. Defina seu ID como Products e, a partir de sua marca inteligente, vincule-o a um novo ObjectDataSource chamado ProductsDataSource. Configure o ObjectDataSource para extrair os seus dados do método da classe ProductsBLL s GetProducts. Este será um GridView somente leitura, portanto, defina as listas suspensas nas guias UPDATE, INSERT e DELETE como (Nenhuma) e clique em Terminar.

Figura 5: Figura 5: Configurar o ObjectDataSource para usar o método Class s ProductsBLL (GetProducts imagem em tamanho real)

Figura 6: Defina as listas de Drop-Down nas guias UPDATE, INSERT e DELETE como (Nenhuma) (Clique para visualizar a imagem em tamanho real)

Depois de concluir o assistente Configurar Fonte de Dados, o Visual Studio criará BoundFields e um CheckBoxField para os campos de dados do produto. Remova todos esses campos, exceto ProductID, ProductName, CategoryID, e CategoryName, e renomeie as propriedades ProductName e CategoryName BoundFields para Produto e Categoria, respectivamente. Na etiqueta inteligente, selecione a opção Ativar Paginação. Depois de fazer essas modificações, a marcação declarativa de GridView e ObjectDataSource deve ter a seguinte aparência:

<asp:GridView ID="Products" runat="server" AllowPaging="True" 
    AutoGenerateColumns="False" DataKeyNames="ProductID" 
    DataSourceID="ProductsDataSource">
    <Columns>
        <asp:BoundField DataField="ProductID" HeaderText="ProductID" 
            InsertVisible="False" ReadOnly="True" 
            SortExpression="ProductID" />
        <asp:BoundField DataField="ProductName" HeaderText="Product" 
            SortExpression="ProductName" />
        <asp:BoundField DataField="CategoryID" HeaderText="CategoryID" 
            SortExpression="CategoryID" />
        <asp:BoundField DataField="CategoryName" HeaderText="Category" 
            SortExpression="CategoryName" />
    </Columns>
</asp:GridView>
<asp:ObjectDataSource ID="ProductsDataSource" runat="server" 
    OldValuesParameterFormatString="original_{0}"
    SelectMethod="GetProducts" TypeName="ProductsBLL">
</asp:ObjectDataSource>

Em seguida, adicione três controles Web do tipo Button acima do GridView. Defina a propriedade de texto do primeiro botão como Atualizar Grelha, a do segundo como Modificar Categorias (COM TRANSACÇÃO) e a do terceiro como Modificar Categorias (SEM TRANSACÇÃO).

<p>
    <asp:Button ID="RefreshGrid" runat="server" Text="Refresh Grid" />
</p>
<p>
    <asp:Button ID="ModifyCategoriesWithTransaction" runat="server"
        Text="Modify Categories (WITH TRANSACTION)" />
</p>
<p>
    <asp:Button ID="ModifyCategoriesWithoutTransaction" runat="server"
        Text="Modify Categories (WITHOUT TRANSACTION)" />
</p>

Neste ponto, o modo Design no Visual Studio deve ser semelhante à captura de tela mostrada na Figura 7.

Figura 7: A página contém um GridView e controles Web de três botões (Clique para visualizar a imagem em tamanho real)

Crie manipuladores de eventos para cada um dos três eventos Button s Click e use o seguinte código:

protected void RefreshGrid_Click(object sender, EventArgs e)
{
    Products.DataBind();
}
protected void ModifyCategoriesWithTransaction_Click(object sender, EventArgs e)
{
    // Get the set of products
    ProductsBLL productsAPI = new ProductsBLL();
    Northwind.ProductsDataTable products = productsAPI.GetProducts();
    // Update each product's CategoryID
    foreach (Northwind.ProductsRow product in products)
    {
        product.CategoryID = product.ProductID;
    }
    // Update the data using a transaction
    productsAPI.UpdateWithTransaction(products);
    // Refresh the Grid
    Products.DataBind();
}
protected void ModifyCategoriesWithoutTransaction_Click(object sender, EventArgs e)
{
    // Get the set of products
    ProductsBLL productsAPI = new ProductsBLL();
    Northwind.ProductsDataTable products = productsAPI.GetProducts();
    // Update each product's CategoryID
    foreach (Northwind.ProductsRow product in products)
    {
        product.CategoryID = product.ProductID;
    }
    // Update the data WITHOUT using a transaction
    NorthwindTableAdapters.ProductsTableAdapter productsAdapter = 
        new NorthwindTableAdapters.ProductsTableAdapter();
    productsAdapter.Update(products);
    // Refresh the Grid
    Products.DataBind();
}

O manipulador de eventos refresh Button s Click simplesmente revincula os dados ao GridView chamando o Products método s GridView DataBind .

O segundo manipulador de eventos reatribui os produtos CategoryID e utiliza o novo método de transação da BLL para realizar as atualizações na base de dados dentro de uma transação. Observe que cada produto s CategoryID é definido arbitrariamente com o mesmo valor que seu ProductID. Isso funcionará bem para os primeiros produtos, uma vez que esses produtos têm ProductID valores que coincidentemente são mapeados para CategoryID válidos. Mas uma vez que os ProductID s começam a tornar-se muito grandes, essa sobreposição coincidente de ProductID s e CategoryID s não se aplica mais.

O terceiro Click manipulador de eventos atualiza os produtos CategoryID da mesma maneira, mas envia a atualização para o banco de dados usando o ProductsTableAdapter método padrão Update s. Esse Update método não encapsula a série de comandos dentro de uma transação, portanto, essas alterações são feitas antes que o primeiro erro de violação de restrição de chave estrangeira encontrado persista.

Para demonstrar esse comportamento, visite esta página através de um navegador. Inicialmente, você deve ver a primeira página de dados, como mostra a Figura 8. Em seguida, clique no botão Alterar Categorias (COM TRANSACÇÃO). Isso causará um postback e tentará atualizar os valores de todos os produtos CategoryID, mas resultará em uma violação de restrição de chave estrangeira (consulte a Figura 9).

Figura 8: Os produtos são exibidos em um GridView paginável (Clique para visualizar a imagem em tamanho real)

Figura 9: A reatribuição das categorias resulta em uma violação de restrição de chave estrangeira (Clique para visualizar a imagem em tamanho real)

Agora clique no botão Voltar do seu navegador e, em seguida, clique no botão Atualizar Grelha. Ao atualizar os dados, você verá exatamente a mesma saída mostrada na Figura 8. Ou seja, mesmo que alguns dos produtos CategoryID tenham sido alterados para valores legais e atualizados na base de dados, eles foram revertidos quando ocorreu a violação da restrição de chave estrangeira.

Agora tente clicar no botão Modificar categorias (SEM TRANSAÇÃO). Isso resultará no mesmo erro de violação de restrição de chave estrangeira (consulte a Figura 9), mas desta vez os produtos cujos CategoryID valores foram alterados para um valor legal não serão revertidos. Pressione o botão Voltar do navegador e, em seguida, o botão Atualizar a grelha. Como mostra a Figura 10, os CategoryID s dos primeiros oito produtos foram reatribuídos. Por exemplo, na Figura 8, Chang tinha um CategoryID de 1, mas na Figura 10 ele foi reatribuído a 2.

Figura 10: Alguns valores de produtos CategoryID foram atualizados enquanto outros não foram (Clique para visualizar a imagem em tamanho real)

Resumo

Por padrão, os métodos de TableAdapter não encapsulam as instruções de banco de dados executadas dentro do escopo de uma transação, mas com um pouco de trabalho podemos adicionar métodos que criarão, confirmarão e reverterão uma transação. Neste tutorial, criamos três desses métodos na ProductsTableAdapter classe: BeginTransaction, CommitTransaction, e RollbackTransaction. Vimos como usar esses métodos junto com um try...catch bloco para fazer uma série de declarações de modificação de dados atômicas. Em específico, criámos o método UpdateWithTransaction no ProductsTableAdapter, que usa o padrão Batch Update para executar as modificações necessárias nas linhas de um fornecido ProductsDataTable. Também adicionámos o método DeleteProductsWithTransaction à classe ProductsBLL na BLL, que aceita um List de valores ProductID como sua entrada e chama o método padrão DB-Direct Delete para cada ProductID. Ambos os métodos começam criando uma transação e, em seguida, executando as instruções de modificação de dados dentro de um try...catch bloco. Se ocorrer uma exceção, a transação é revertida, caso contrário, é confirmada.

A etapa 5 ilustrou o efeito das atualizações em lote transacionais versus as atualizações em lote que negligenciaram o uso de uma transação. Nos próximos três tutoriais, vamos construir sobre a base estabelecida neste tutorial e criar interfaces de usuário para executar atualizações em lote, exclusões e inserções.

Feliz Programação!

Leitura adicional

Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:

• Transações facilitadas: System.Transactions
• TransactionScope e DataAdapters
• Usando transações de banco de dados Oracle no .NET

Sobre o Autor

Scott Mitchell, autor de sete livros sobre ASP/ASP.NET e fundador da 4GuysFromRolla.com, trabalha com tecnologias Web da Microsoft desde 1998. Scott trabalha como consultor, formador e escritor independente. Seu último livro é Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Ele pode ser contatado em mitchell@4GuysFromRolla.com.

Um agradecimento especial a

Esta série de tutoriais foi revisada por muitos revisores úteis. Os principais revisores deste tutorial foram Dave Gardner, Hilton Giesenow e Teresa Murphy. Interessado em rever meus próximos artigos do MSDN? Se for o caso, envie-me uma mensagem para mitchell@4GuysFromRolla.com.

Seguinte