"Se tens N dbContexts tens de ter cuidado com as ligações às BD"
Bingo, foi precisamente isto que eu suspeitei e não gostei muito da ideia
de múltiplos contexts.

"obviamente o impacto que podes ter em "queues" de queries que podes criar
..."
Pois ...

"Explicitamente marca o contexto como leitura ou não para ele não andar a
fazer tracking das mudanças."
Boa, boa dica.
Tenho áreas que é mesmo só de leitura (por exemplo para reporting) e outras
leitura/escrita.
Isto já irá minimizar um pouco mais o impacto.

"E Se estás em MVC podes injetar para o controller o dbContext ...escusas
de estar sempre a criar pois depende do lazy loading ou eager loading podes
MATAR a performance..."
Sim, isto também já andei a tratar.

Por aquilo que referes, já aplico a maioria das boas práticas.
Falta mesmo só marcas alguns como read-only e evitar o custo acrescido de
ter o tracking para persistência totalmente desnecessário.

Estou a seguir uma abordagem EF mas não para todas as alterações.
Para deletes/updates que ainda não tenho nem necessito do objeto em
memória, é sql direto !
O EF é bom mas como qualquer ORM não é para tudo.







No dia 21 de janeiro de 2016 às 15:43, Cristovão Morgado <
[email protected]> escreveu:

> Estás naturalmente numa app web certo?
>
> Para projetos pequenos / médios uso apenas 1 contexto. para GRANDES nem
> uso EF ... faço mesmo com o "driver" correcto da BD (tipo SQLConnection e
> OracleConnection e tudo à mão ... naturalmente uso T4 para me gerar a DAL)
>
> 1º Se tens N dbContexts tens de ter cuidado com as ligações às BD
> 2º obviamente o impacto que podes ter em "queues" de queries que podes
> criar ...
> 3º Explicitamente marca o contexto como leitura ou não para ele não andar
> a fazer tracking das mudanças.
>
> E Se estás em MVC podes injetar para o controller o dbContext ...escusas
> de estar sempre a criar pois depende do lazy loading ou eager loading podes
> MATAR a performance...
>
>
>
> Best regards
> Cristóvão Morgado
> pt.linkedin.com/in/cmmorgado/
> github.com/cmorgado
>
>    -
>
>
>
> 2016-01-21 15:29 GMT+00:00 Hugo Ferreira <[email protected]>:
>
>> Boa tarde,
>>
>> Estou a trabalhar com o EntityFramework 6 (abordagem Code-First) e tenho
>> aqui uma dúvida conceptual.
>> Esta questão existe na net com frequência e encontro diversas opiniões,
>> pelo que não é unanimo.
>>
>> Começei por usar um DbContext (que extende de um base meu já devidamente
>> configurado) por entidade e cheguei à conclusão que não final fiquei com
>> demasiadas classes "vazias" e optei por mudar para um DbContext único com
>> todas as referências a entidades que o mesmo tive-se que lidar durante o
>> ciclo da aplicação (nem todas são utilizadas, dependendo do controlo que
>> tiver a usar mas muitas são partilhadas entre controlos).
>>
>> Este método acaba por ter um DbContext com muitas referências mas
>> evita-se dezenas de classes vazias (manter simples).
>>
>> Existe algum problema de performance com esta abordagem ?
>>
>> Vejo que há quem diga que o melhor é não ter um DbContext por entidade
>> nem um único geral mais sim um por módulo funcional. O problema é que
>> existe algumas entidades que seriam comuns a este módulos e acabaria por
>> ter de repetir.
>> Outro problema (ainda não testei este caso) e comigo ia acontecer com
>> freqeência, é a necessidade de uma transação partilhada entre contextos e
>> penso que aqui tinha de andar a partilha a transcação do primeiro contexto
>> com os restantes.
>>
>> --
>> Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da
>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do
>> Grupos do Google.
>> Para anular a subscrição deste grupo e parar de receber emails do mesmo,
>> envie um email para [email protected].
>> Para publicar uma mensagem neste grupo, envie um email para
>> [email protected].
>> Visite este grupo em https://groups.google.com/group/riapt.
>> Para mais opções, visite https://groups.google.com/d/optout.
>>
>
> --
> Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da
> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do
> Grupos do Google.
> Para anular a subscrição deste grupo e parar de receber emails do mesmo,
> envie um email para [email protected].
> Para publicar uma mensagem neste grupo, envie um email para
> [email protected].
> Visite este grupo em https://groups.google.com/group/riapt.
> Para mais opções, visite https://groups.google.com/d/optout.
>

-- 
Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade 
Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google.

Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie 
um email para [email protected].
Para publicar uma mensagem neste grupo, envie um e-mail para 
[email protected].
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, consulte https://groups.google.com/d/optout.

Responder a