LINQ to SQL: Persistindo dados

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 necess ...