Miguel, Descreveste sem tirar nem por a estratégia de implementação do estado atual (após vários refatorings e testes). Obrigado. Vou manter a abordagem atual e após marcar alguns objectvos como read-only.
No dia 21 de janeiro de 2016 às 16:06, Miguel Vaz <[email protected]> escreveu: > > Dependendo do projecto, claro, optaria por um unity of work com uma data > access layer para evitar chatices a utilizares dbcontext em todos os teus > controllers(se calhar já fazes isso). Tanto que, mais tarde, para eventuais > alterações, torna as coisas mais fáceis e contidas (e é o correcto). > > É difícil dar opiniões sem conhecer ao certo o peso e frequência das > queries, mas se o projecto não é demasiado grande, pensaria no que disse > acima, com um (apenas um) dbcontext numa layer abaixo. Nas chamadas à unity > pensava na estratégia de asyncs para optimizar (palavra polémica) as > chamadas à bd. > > Espero que ajude mais uma opinião. :) > > Miguel > On Jan 21, 2016 3:54 PM, "Hugo Ferreira" <[email protected]> wrote: > >> "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 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.
