Estou escrevendo um artigo para a .Net Magazine e resolvi usar em um dos exemplos a persistência "pré-fabricada" do LINQ to SQL. Até aí tudo bem, mas qual não foi minha surpresa ao perceber que não há muito suporte de LINQ to SQL para programação multi-camadas. Já repararam que todos os exemplos que vemos com LINQ to SQL estão usando sempre 2 camadas (apresentação e banco de dados)?

Descobri que algumas pessoas já estão reclamando disso a algum tempo. Alguns artigos que li sugerem o uso de uma camada adicional de abstração, algo sugerido pelo próprio Scott Guthrie da Microsoft em seu blog, onde ele também comenta que vai fazer um post sobre n-camadas e LINQ to SQL, que até agora eu não vi (ele comenta novamente, dessa vez no próprio post, aqui).

Isso tudo é muito estranho. Uma das coisas que senti falta foi a possibilidade de separar as entidades de negócio do código de acesso a dados, algo que o Visual Studio 2008 já oferece para os Datasets tipados:

Porque não oferecer o mesmo suporte ao LINQ to SQL? Procurei bastante, mas não encontrei nada parecido no Designer:

Outro problema encontrado foi a utilização de um objeto modificado com outra instância de datacontext. Tudo indica que não funciona…

Vou procurar um pouco mais e ver no que dá. Se encontrar solução coloco por aqui.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.