O Cristovão completou o meu email. Esqueci-me de referir o repository. Essencial para manter as coisas organizadas em projectos maiores. :)
Miguel On Jan 21, 2016 4:09 PM, "Hugo Ferreira" <[email protected]> wrote: > 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 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.
