arquitetura de três camadas e LINQ to Entities
-
10-07-2019 - |
Pergunta
Para um par de anos, eu estive usando a arquitetura de três camadas (Apresentação, Lógica e Dados Layer) para aplicações de gravação. Normalmente, eu estou usando ferramentas como .netTiers para gerar a camada de dados e parcialmente a camada de lógica. Tudo está bem definido e eu adoro isso.
Agora estou restrição para usar o LINQ to Entites (parece que LINQ to SQL foi abandonada pela Microsoft) e eu estou realmente confuso. Parece-me que o código gerado pelo LINQ para Entites é uma grande mistura de lógica e camada de dados no qual eu tenho muito pouco controle. Além disso, eu realmente não gosto do fato de que eu tenho que usar as classes (entidades ...) gerados.
No final, você poderia compartilhar suas experiências e melhores práticas com o LINQ to Entities? Alguma idéia de como eu poderia ainda ter uma arquitetura de três camadas bem definidas?
Obrigado!
Solução
Ian Cooper escreveu boa série sobre arquitetura de aplicativo usando Linq2Sql:
- Parte 1 Introdução
- Parte 2 Layered Arquiteturas
- Parte 3 DAOs e Repositórios
- Parte 4 consultas dinâmicas
- Parte 5
- Parte 6 Mapeamento com arquivos XML em vez de Atributos
- Parte 7
- Parte 8
- Parte 9
- Parte 10
A esperança de encontrar o que você precisa.
Outras dicas
L2S não está morta, mas é basicamente completa. Seu uma implementação (SQL Adapter) para Linq. Linq é um recurso de linguagem e continuará a expandir como versões .net são liberados.
O que faz Linq bela é a simplicidade. Eu, pelo menos, além de provedores adicionais (como o MySQL, Firebird, etc ...) eu realmente não quero que eles muck-lo.