Revista MSDN Magazine Edição 21 - Coleções e Data Binding

Clique aqui para ler todos os artigos desta edição

Coleções e Data Binding

por Dino Esposito

Quando chegar a hora de projetar a Data Access Layer (DAL) de seu aplicativo Microsoft® .NET Framework distribuído, uma das principais decisões que você deverá tomar é como transferir os dados entre os métodos das classes DAL. Existem algumas opções para passar os dados de negócios de/para as classes DAL, mas, no mundo real, as escolhas se resumem a apenas duas — o uso de objetos DataSet ou de coleções de objetos de entidades de negócios. A série de artigos e livros "Patterns and Practices" fornecem algumas orientações sobre as práticas implementadas com mais freqüência. Por exemplo, os problemas relacionados à passagem dos dados entre as camadas de dados são amplamente analisados no artigo em Designing Data Tier Components and Passing Data Through Tiers (http://msdn.microsoft.com/library/en-us/dnbda/html/BOAGag.asp). Para obter uma lista mais completa, consulte http://msdn.microsoft.com/architecture/patterns.

Os DataSets possuem suporte incorporado para concorrência otimista e a capacidade de definir e tratar relações complexas entre as tabelas. Os DataSets também são serializáveis e geralmente não requerem alterações na API DAL se o esquema de banco de dados relevante for alterado. Da mesma forma, as coleções de objetos personalizados oferecem suporte à serialização e não requerem nenhuma alteração de assinatura de método se os esquemas de banco de dados forem modificados. As coleções também evitam as penalidades de desempenho nas quais os DataSets podem incorrer. Por exemplo, o marshaling do DataSet pode ser problemático quando existem milhares de linhas de dados envolvidas. Os DataSets são particularmente adaptados para a movimentação de conjuntos de dados; no caso de métodos que necessitam instanciar dados e escalar valores, uma abordagem baseada em entidades de negócios personalizadas talvez seja preferível.

Os dados que as classes DAL recuperam serão freqüentemente vinculados aos controles Windows® e Web Forms e geralmente usados para atender solicitações de Web services. Descobri que a maioria dos livros e artigos (incluindo o meu) tendem a abordar a maioria do data binding da perspectiva do DataSet. Aqui, analisarei o data binding com as coleções personalizadas a partir de todas as perspectives — Windows Forms, Web Forms e Web services. No entanto, antes de passar adiante, darei um rápido lembrete sobre as coleções do .NET Framework 1.x, bem como uma olhada de relance no .NET Framework 2.0.

Fundamentos básicos das coleções

Uma coleção consiste em um conjunto de objetos homogêneos que são gerenciados por meio da interface de uma classe container. Uma coleção é uma entidade tipada; com isso, todos os objetos contidos concordam com o mesmo tipo declarado. O .NET define diferentes tipos de coleções; cada uma delas mapeia para uma estrutura de dados diferente — queue, stack (pilha), list, hashtable, e mais. Vamos comprar as várias classes de coleção.

O .NET Framework oferece várias classes de coleção, e todas parecem iguais à primeira vista. Assim, como você pode ter certeza que obteve a classe mais apropriada à sua tarefa? Quanto mais especializada for uma coleção, mais limitada ela será, mas também a melhor em determinadas situações. A Tabela 1 lista as classes de coleção usadas no .NET Framework 1.x. Para cada classe, é possível ver a principal interface que ela implementa e o namespace de origem. A Tabela 2 detalha as características das interfaces por trás das coleções.

Tabela 1 Classes de Coleção no .NET Framework 1.x