A MAIOR vantagem do repository é trocas de repositório por injecção... Hoje estás na BD x amanhã numa Y .... ou numa noSQL!
O Unit Of Work garante-te o que os apaixonados das BD relacionais gostam.... a atomicidade de uma operação com direito à transactions ;) .... rollback simple .. Best regards Cristóvão Morgado pt.linkedin.com/in/cmmorgado/ github.com/cmorgado - 2016-01-21 16:57 GMT+00:00 Miguel Vaz <[email protected]>: > 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 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.
