Artigos .NET LINQ to SQL: Persistindo dados
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Artigo no estilo Solução Completa
Porque esse artigo é útil
Arquiteturas de aplicações no estilo da Microsoft são totalmente vedadas em todos os seus nós de integração. O LINQ to SQL é uma solução simples e robusta para aplicações que não necessitem de um grande poder e complexidade existente em aplicações corporativas de maior porte. O LINQ to SQL é bastante leve, performático e escalável, tanto que a própria Microsoft o recomenda ao invés do LINQ to Entities ou Microsoft ADO.NET Entity Framework – em aplicações menores e de pouco fluxo de informações tais como um Sistema de Controle de Estoque de pequenas redes de varejo, supermercados de bairro ou pequenas e médias empresas. Para empresas que precisem de Sistemas Internos e com bom volume de acesso, o LINQ to SQL é altamente recomendado.

Muitos sistemas desenvolvidos hoje em dia manipulam dados de uma forma ou de outra e frequentemente seus dados são gravados em um Banco de Dados Relacional. De certa forma, há uma enorme divisão entre Linguagens de Programação modernas e Bancos de Dados e em como estes representam e manipulam a informação. Esta divisão é vista de muitas formas. Nota-se mais este fenômeno na forma como as Linguagens de Programação acessam a informação em Bancos de Dados através de APIs que necessitam de consultas que sejam criadas de forma manual, via texto. Tais consultas são porções significativas de lógica, mas sendo ocultas à Linguagem, impossíveis de terem seu benefício evidenciado em verificações durante a compilação e no momento da modelagem como o IntelliSense. É certo que as diferenças vão muito mais além e são muito mais profundas do que estas. A informação representada, pelo menos no modelo de dados, é um pouco diferente entre linguagens e bancos. Linguagens de Programação modernas definem informação em forma de objetos. Bancos de Dados Relacionais usam linhas. Objetos tem identidade única em cada uma de suas instâncias e cada uma destas é fisicamente diferente de outra, além de referências que identificam e conectam instâncias. Linhas são identificadas por valores de chave primária e intencionalmente são distintas se conectam a outras linhas que serão conectadas entre si de forma mais fraca utilizando chaves estrangeiras. Além disso, existem como elementos de Tabelas, sendo eliminadas assim que são removidas destas. Objetos autônomos existem até serem referenciados por outros objetos

Diante deste embate de paradigmas, não é novidade que aplicações, em que esperamos fechar esta lacuna de comunicação entre Linguagens de Programação e Bancos de Dados, são tão difíceis de construir e manter. Facilmente, para solucionar este problema da forma mais humana possível, a saída seria eliminar um dos lados e pronto: teremos uma solução. Diante disso, temos de um lado os Bancos de Dados Relacionais que nos disponibilizam uma infraestrutura crítica para armazenamento de longo tempo e processamento de consultas, e em outro extremo as Linguagens de Programação modernas que são indispensáveis para a computação rica e o desenvolvimento ágil.

A melhor solução precisa ser elaborada para abstrair o Banco de Dados em camadas de Aplicação e Dados de forma separada, mantendo a informação entre o domínio específico da aplicação em seus modelos de dados e diferir de uma representação tabular como o é refletido no Banco de Dados, sempre reformulando e reformatando o dado em cada um destes extremos. Na melhor das hipóteses, escondendo a verdadeira fonte de dados, até como uma forma de segurança, estas soluções tendem a descartar o recurso mais utilizado nos Bancos de Dados: a capacidade de consulta dos dados brutos.

Vemos o caso da Microsoft que para Arquiteturas Corporativas conjugou o Visual Studio, o .NET Framework, o SQL Server, o Entity Framework. Se notar, já temos uma arquitetura cliente servidor totalmente Microsoft com toda a estabilidade que os produtos suportam para grandes projetos.

Porém, vemos toneladas de bytes sendo escritos para arquiteturas corporativas onde o uso e o acesso às mesmas é muito pequeno visto do prisma de uma grande aplicação corporativa. Diante disso, temos um custo maior para uma aplicação que não irá precisar totalmente da potência de um ambiente altamente robusto e estamos em uma época em que robustez extrema é sinônimo de alto custo. Exemplos disso podem ser aplicativos que sejam utilizados no setor de varejo, como um sistema de controle de estoque de uma padaria, minimercado ou mercearia. Indo ainda mais além, podemos não precisar de uma arquitetura com Entity Framework para um controle de ponto de venda de um minimercado. Para este fim, existe uma arquitetura mais “leve”, mais simples e que não necessita de uma abstração tão grande. Para uma arquitetura livre de grandes acessos e principalmente com massas de dados médias utilizadas em paralelo e não ter nenhuma necessidade de se utilizar grandes consumos de banda e processamento dentro de um ambiente Microsoft, foi criado o LINQ to SQL, que vem para suprir esta necessidade com alta produtividade e baixo custo. Baixo custo significa baixa curva de aprendizado. A implementação do LINQ to SQL não deixa em hipótese alguma a desejar comparado ao seu “rival” ADO.NET Entity Framework quando o assunto é persistência e Mapeamento de Objeto Relacional.

LINQ to SQL: o que é?

O Language Integrated Queries to Microsoft SQL Server, ou LINQ to SQL, é um componente do Visual Studio que disponibiliza a infraestrutura em tempo de execução para gerenciar dados como objetos, sem perder a habilidade de consultá-los como e quando for preciso. O LINQ to SQL é um framework de Mapeamento Objeto Relacional, mas não encapsula totalmente o SQL como outros existentes no mercado. Sua aplicação é livre para manipular objetos enquanto o LINQ to SQL fica em segundo plano rastreando as mudanças efetuadas em seu modelo de dados automaticamente.

Por estar usando o LINQ to SQL, você utilizará a tecnologia LINQ para acessar bancos de dados SQL tão facilmente como se acessaria uma coleção de objetos diretamente da memória da máquina.

O LINQ to SQL é desenhado para não ser intrusivo nas aplicações onde é utilizado. Uma vantagem deste desenho é a possibilidade de migração de qualquer solução ADO.NET atual para o LINQ to SQL em módulo, de forma bastante organizada, compartilhando as mesmas transações e conexões. O que facilita esta migração é que o próprio LINQ to SQL também é um componente da família ADO.NET. O LINQ to SQL tem suporte à extensão para uso de Stored procedures, permitindo o reuso de recursos já existentes dentro da aplicação corporativa.

Aplicações utilizando LINQ to SQL são fáceis de serem desenvolvidas. Objetos conectados aos dados relacionais podem ser definidos como objetos normais, apenas decorados com atributos para identificar quais propriedades correspondem a tais campos da tabela dentro de um banco de dados. Mas nem sempre é necessário fazer isso manualmente, uma ferramenta para modelagem é disponibilizada para automaticamente traduzir esquemas já existentes de bancos de dados para objetos definidos pelo desenvolvedor. Porém, neste artigo vamos cobrir o mapeamento manual das classes de persistência.

Mapeamento utilizando atributos

LINQ to SQL mapeia um banco de dados do SQL Server para um Modelo de Objetos aplicando atributos nas classes deste modelo ou utilizando um arquivo de mapeamento. Como o arquivo de mapeamento foge totalmente do intuito deste artigo, ele não será abordado, mas para conhecê-lo mais detalhadamente, verifique a seção Links ao final do artigo.

Em sua forma mais simples, LINQ to SQL mapeia um banco de dados para um DataContext, uma tabela para uma classe e colunas e relacionamentos para propriedades dentro destas classes. Você também pode usar atributos para mapear uma hierarquia de heranças em seu modelo de objetos.

As seções seguintes descrevem mapeamentos baseados em atributos em maiores detalhes. Estes atributos estão presentes no namespace System.Data.Linq.Mapping.

Atributo Database

Use este atributo para especificar o nome padrão do banco de dados quando o nome não é disponibilizado pela conexão. Este atributo é opcional, mas se for utilizado, é necessário que se utilize a propriedade Name, como descrito na Tabela 1. Segue também um exemplo de implementação na Listagem 1.

Tabela 1. Propriedades do Atributo Database

Listagem 1. Implementação do atributo Database e suas propriedades


  01 [Database(Name = "ARTIGOGABRIEL_01")]
  02 public class FonteDeDados : DataContext
  03 {
  04 }

Atributo Table

Use este atributo para designar uma classe como uma classe de entidade que é associada a uma tabela ou view do banco de dados. LINQ to SQL trata classes que tenham este atributo como classes de persistência. Na Tabela 2 temos as propriedades que podem ser utilizadas junto com este atributo.

abrir imagem em nova janela

Tabela 2. Propriedades do atributo Table

Já na Listagem 2 temos a impleme ...

Quer ler esse conteúdo completo? Tenha acesso completo