none
Arquitetura e Entity Framework RRS feed

  • Pergunta

  • Pensando em uma boa Arquitetura, é aconselhavel encapsular todas as chamadas ao Context do EF4 em uma classe de repositório, ou posso considerar que meu próprio Context já é o Repositório?

    Por exemplo em ASP.NET MVC, eu posso usar o Context direto no controller, pegando as entidades que preciso pra enviar pra View?

    As vezes acho que criar um repositorio é "over-design", pois estamos refazendo o que o EF já faz. Alem de ter que criar um método novo pra cada Where, OrderBy ou Select diferente.


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    quinta-feira, 23 de setembro de 2010 11:18

Respostas

  • Seilor,

     

    Talvez seria bem interessante, uma vez que a arquitetura montada ficou tão interessante, montar um simples artigo com exemplos, assim poderiamos entender como é uma arquitetura bem montadinha com EF4, POCO e Repository.

     

    Tá aí uma sugestão legal, caso você goste de escrever artigos...

     

    Abraço!


    Eduardo,

    Gosto sim de escrever mais no momento estou bem ocupado, mais tem alguma referencias que seria legal vc dar uma olhada

    http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/

    http://blog.answermyquery.com/2009/12/entity-framework-poco-ef4-generic-repository-and-unit-of-work-prototype/

    http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx

     

    lembrando que tem que ser o EF 2, que so tem no frame 4.0

    sexta-feira, 24 de setembro de 2010 17:02
  • Ola,

    Isso e so exemplos vc vai adequando para seu framework, o unit e necessario quando vc for fazer varias transacoes, pois vc tem que manter o mesmo context

    domingo, 26 de setembro de 2010 18:14
  • Felipe

    Não vejo duplicação, pelo contrário, a classe abstrata já implementa os métodos CRUD (que são os mais comuns), portanto todas as implementações do repositório herdam dela e não precisarão implementar esses métodos todos de novo. Você tem um ganho enorme aí de reaproveitamento de código.

    Qto ao UoW, sim, o EF já implementa este padrão. Porém, utilizar uma interface IUnitOfWork desacopla sua app do EF. A idéia é não depender do EF. Caso você queira trocar o Entity por NHibernate, por exemplo, fica muito mais simples.

    A mesma idéia vale para o fato de se utilizar diretamente o contexto nos controllers (estes estarão diretamente dependentes do EF).

    Dependendo de abstrações, ao invés de classes concretas, você torna mais fácil a manutenção do software.

    []s

     


    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications
    MCP Virtual Card: https://www.mcpvirtualbusinesscard.com/VBCServer/robsoncastilho/profile
    [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    domingo, 26 de setembro de 2010 20:21
  • Opa Felipe

    Não é apenas questão de poder trocar de DAL. O uso de interfaces permite, por exemplo, usar um container de DI para injectar os objetos pra você, além de favorecer a realização de testes unitários.

    Mas, é claro, depende também da aplicação, da equipe, prazo, enfim....Não vale a pena montar uma arquitetura "monstruosa" para fazer uma pequena tela de cadastro para ser usada por alguns meses.

    Qto mais conhecermos, maior nosso leque de opções :)

    []s

     


    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications
    MCP Virtual Card: https://www.mcpvirtualbusinesscard.com/VBCServer/robsoncastilho/profile
    [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    terça-feira, 28 de setembro de 2010 01:04

Todas as Respostas

  • Cara depende muito da sua arquitetura, eu estou usando repository com ef 4 com classes poco funciona que um blz em um sistema de grande porte, e a manutencao e simples pois meu projeto de acesso a base vc feito com genercis em poucas classes eu consigo atender varios requisitos
    quinta-feira, 23 de setembro de 2010 12:26
  • Você fez um RepositorioBase ja com BuscarPorId, Insert, etc, e todos seus POCOs herdam de um Entity que tem a propriedade Id?

    Estou usando EFv1 e não tem POCO. Será que é uma boa pratica retornar os objetos do EF, ou é melhor mapear pra objetos de negocio a parte? Ex.: return MapperToProdutoBO(Context.Produto.First());


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    quinta-feira, 23 de setembro de 2010 13:59
  • Seilor,

     

    Talvez seria bem interessante, uma vez que a arquitetura montada ficou tão interessante, montar um simples artigo com exemplos, assim poderiamos entender como é uma arquitetura bem montadinha com EF4, POCO e Repository.

     

    Tá aí uma sugestão legal, caso você goste de escrever artigos...

     

    Abraço!

    quinta-feira, 23 de setembro de 2010 16:43
  • Felipe,

    De uma olhada nesse site. www.totalcodegenerator.com.br

    Ele tem um gerador de código bem legal, e esta disponível para testar gratuitamente projetos de até 20 tabelas de banco de dados.

    Ele possuiu uma camada de entidades que voce pode dar  uma olhada.

    Espero ter ajudado.

     

     

    quinta-feira, 23 de setembro de 2010 18:59
  • Não achei onde baixa o software
    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    quinta-feira, 23 de setembro de 2010 23:04
  • Felipe,

    É tudo online.

    voce baixa seu código já pronto.

     

    sexta-feira, 24 de setembro de 2010 14:42
  • Você fez um RepositorioBase ja com BuscarPorId, Insert, etc, e todos seus POCOs herdam de um Entity que tem a propriedade Id?

    Estou usando EFv1 e não tem POCO. Será que é uma boa pratica retornar os objetos do EF, ou é melhor mapear pra objetos de negocio a parte? Ex.: return MapperToProdutoBO(Context.Produto.First());


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4


    Felipe,

    Com a versao 1 eu nao seria muito a favor de usar ef pois pelo que eu lembre ele nao tem lazyloading e isso pode afetar seu sistema, talvez com a 3.5 seria melhor vc usar o linq to sql se for para uma sistema pequeno, o senao usar o nhibernate

     

    sexta-feira, 24 de setembro de 2010 17:00
  • Seilor,

     

    Talvez seria bem interessante, uma vez que a arquitetura montada ficou tão interessante, montar um simples artigo com exemplos, assim poderiamos entender como é uma arquitetura bem montadinha com EF4, POCO e Repository.

     

    Tá aí uma sugestão legal, caso você goste de escrever artigos...

     

    Abraço!


    Eduardo,

    Gosto sim de escrever mais no momento estou bem ocupado, mais tem alguma referencias que seria legal vc dar uma olhada

    http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/

    http://blog.answermyquery.com/2009/12/entity-framework-poco-ef4-generic-repository-and-unit-of-work-prototype/

    http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx

     

    lembrando que tem que ser o EF 2, que so tem no frame 4.0

    sexta-feira, 24 de setembro de 2010 17:02
  • Seilor,

    Estes exemplos são exatamente o que acho duplicação de funcionalidade. Por exemplo no primeiro link, até o contexto ele expõe como IQueryable, então não da pra dizer que é pra evitar o acesso à ele.

    E não vejo vantagem em ficar duplicando o First, Single e Where. Acho que é "over-design". Até o Unit Of Work, se você for ver ele não faz nada, pois o próprio EF já tem essa função.


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    sexta-feira, 24 de setembro de 2010 18:15
  • Ola,

    Isso e so exemplos vc vai adequando para seu framework, o unit e necessario quando vc for fazer varias transacoes, pois vc tem que manter o mesmo context

    domingo, 26 de setembro de 2010 18:14
  • Felipe

    Não vejo duplicação, pelo contrário, a classe abstrata já implementa os métodos CRUD (que são os mais comuns), portanto todas as implementações do repositório herdam dela e não precisarão implementar esses métodos todos de novo. Você tem um ganho enorme aí de reaproveitamento de código.

    Qto ao UoW, sim, o EF já implementa este padrão. Porém, utilizar uma interface IUnitOfWork desacopla sua app do EF. A idéia é não depender do EF. Caso você queira trocar o Entity por NHibernate, por exemplo, fica muito mais simples.

    A mesma idéia vale para o fato de se utilizar diretamente o contexto nos controllers (estes estarão diretamente dependentes do EF).

    Dependendo de abstrações, ao invés de classes concretas, você torna mais fácil a manutenção do software.

    []s

     


    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications
    MCP Virtual Card: https://www.mcpvirtualbusinesscard.com/VBCServer/robsoncastilho/profile
    [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    domingo, 26 de setembro de 2010 20:21
  • Essa questão de trocar o ORM também acho que é muito valorizada mas pouco utilizada. Acho que é como usar SProc achando que quando quiser trocar de banco de dados não vai ter dor de cabeça, o que não é verdade.

    Mesmo que seu código seja dependente apenas de interfaces e use IoC, não adianta, o comportamento dos ORM são diferentes, tem muitas coisas que contam, se suporta POCO, Lazy Loading, Change Tracking, Transação, etc.

    Tem até um artigo do Ayende, um dos principais desenvolvedor do NHibernate, "The false myth of encapsulating data access in the DAL" onde ele fala justamente sobre isso: http://ayende.com/Blog/archive/2010/07/30/the-false-myth-of-encapsulating-data-access-in-the-dal.aspx


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    domingo, 26 de setembro de 2010 21:21
  • Opa Felipe

    Não é apenas questão de poder trocar de DAL. O uso de interfaces permite, por exemplo, usar um container de DI para injectar os objetos pra você, além de favorecer a realização de testes unitários.

    Mas, é claro, depende também da aplicação, da equipe, prazo, enfim....Não vale a pena montar uma arquitetura "monstruosa" para fazer uma pequena tela de cadastro para ser usada por alguns meses.

    Qto mais conhecermos, maior nosso leque de opções :)

    []s

     


    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications
    MCP Virtual Card: https://www.mcpvirtualbusinesscard.com/VBCServer/robsoncastilho/profile
    [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    terça-feira, 28 de setembro de 2010 01:04