A EF é uma equipe muito usada, mas não sei como devo usá-la. Conheci muitos problemas com ef em diferentes projetos com diferentes abordagens. Então, algumas perguntas foram reunidas na minha cabeça. E as respostas me levam a usar o ado.net.net puro com procedimentos armazenados. Então, as perguntas são:

Como lidar com a EF na aplicação de n camadas? Por exemplo, temos alguns DAL com EF. Eu vi muitos artigos e projetos que usavam repositórios, padrões de unidade de trabalho como algum tipo de abstração para a EF. Eu acho que essa abordagem mata a maioria dos benefícios que aumentam a velocidade de desenvolvimento e levam a poucas coisas:o remapeamento da carga EF resulta em algum DTO que prejudica o desempenho (chame alguns select para obter dados da tabela - primeiro loop, segundo loop - mapeie os resultados para algum tipo composto gerado por ef, próximo - filtre os dados mapeados usando linq e, finalmente, mapeie-os para algum DTO). O remapeamento exato do DTO é um dos maiores benefícios do efs;
ouleva a fortes coesões entre a EF (e éversão) e aplicativo. Será algo como um aplicativo de duas camadas com dal e apresentação com bll ou dal com bll e apresentação. Eu acho que não é uma prática recomendada. E o mesmo processo de carregamento que temos para a coisa anterior, exceto o mapeamento, de novo o problema de desempenho levantado. Poderíamos tentar usar EF como DAL sem qualquer abstração sob eles. Mas teremos problemas semelhantes de alguma outra maneira.

Devo usar um contexto por operação app \ thread \ atomic? Usando a abordagem - um contexto por aplicativo \ thread pode aumentar um pouco o desempenho e as possibilidades de chamar propriedades de navegação, mas encontramos outro problema: atualizar esse contexto e aumentar os dados carregados no contexto, também não tenho certeza sobre a simultaneidade com um dbcontext por aplicativo \ fio. Usar o contexto por operação nos levará a remapear os resultados ef para nossos DTOs. Então você vê que voltamos novamente à pergunta no.1.

Podemos tentar usar apenas EF + SP? Novamente, temos problemas de perguntas anteriores. Qual o motivo de usar ef se a maior parte da funcionalidade não será usada?

Então, sim, a EF é ótima para começar o projeto. É muito conveniente quando temos poucas telas e operações brutas. Mas o que vem depois?

Todo este texto é apenas pensamentos não ordenados. Eu sei que o puro ado.net levará a outro tipo de desafios. Então, qual sua opinião sobre esse tópico?