none
O que usar e por onde começar... RRS feed

  • Pergunta

  • Olá senhores, bom dia!

    Preciso aprender EntityFramework e tudo de novo que está envolvido com ele. Pra isso, comecei a desenvolver um projetinho simples para utilizar a tecnologia e alguns padrões de projeto, mas estou com dificuldades.

    Qual a melhor camada de persistência para utilizar com Entity Framework(Dao, Repository) ou existe alguma melhor?

    Estou acostumado a usar o padrão DAO e DTO para transferencia de dados entre camadas.... Como funciona isso no Entity utilizando ele isolado na camada de dados?  DTO funciona? É o melhor a usar?

    MVC + DAO + Entity combinam ? Onde entra o POCO nisso?

    Desculpem a ignorância mas não estou conseguindo associar tudo, acho que preciso saber mais sobre a tecnologia antes de entender os padrões aplicados com ela. =D 

    Obrigado a todos que ajudarem!


    segunda-feira, 20 de agosto de 2012 12:26

Respostas

  • Ola amigos, bom dia!  Após um tempo estudando a arquitetura MVC e o Entity framework, voltei aqui para responder a minha própria duvida. :)

    A resposta para ela é simples, vamos la:

    • Tudo está completamente ligado. A POCO ela vai ter utilidade para você retirar as classes de mapeamento de objeto(classes de transferencia) do edmx, mas só vi necessidade de fazer isso caso você queira alterar alguma propriedade da mesma.  EX - Tem um campo IDADE e quero colocar uma regra de idade no SET do do mesmo, sem o POCO eu posso fazer isso normalmente, acho a propriedade mapeada no codigo do edmx e aplico o que eu quero, porem quando eu atualizar o edmx isso vai ser perdido pois ele vai alterar todas as classes e propriedades gerando elas tudo novamente. Já com o POCO você não vai se preocupar com isso pois as suas classes de mapeamento de objeto vão ficar separadas. POCO = DTO .. rsrs  

    • Não vejo necessidade de usar Repository a não ser se desacoplar o seu modo de acesso a dados do resto mas isso fica legal se desacoplar as Dependências. A ideia do repository é criar uma camada de abstração acima da camada de acesso a dados(Cria uma porrada de interfaces e desacopla como vai ser acessado os dados, pois vai estar tudo em interface, as BusinessRules vão utilizar as interfaces e vai ter um metodo que vai "INJETAR", vai preencher essa interface com o Repositório que você precisa....) EX - Tenho um Repositorio de CLIENTE para MYSQL e otro para SQL.... Para a minha classe de Negocio(BusinessRules) vai ser independente qual eu vou usar, pois la vai estar implementando as interfaces em comum com os 2 repositorios, o que vai distinguir se eu vou usar SQL ou MYSQL vai ser o metodo que vai INJETAR,IMPLEMENTAR, CRIAR essa interface para mim.... vai ter um lugar la que vai ter uma condição(SE FOR ISSO, CRIA REPOSITORIO SQL, SE FOR AQUILO CRIA O REPOSITORIO MYSQL). 

    Lembrando que isso não vai desacoplar o seu projeto da camada de acesso a dados, pois se sua camada de acesso a dados usa o EF, você vai ter que ter as dependencias do EF acoplado em todos os projetos que utilizam essa forma de acesso a dados... para evitar isso você aplica o Dependency Injection(Pesquisem por Ninject ou UNITY). PS - Prefiro o NInject.

    Obrigado a todos que tentaram me ajudar, mas essa é a resposta... No final de tudo a conclusão é: Use o que for melhor para você. +D

    quinta-feira, 22 de novembro de 2012 12:24

Todas as Respostas

  • Com nhibernate eu até usava Repository, com o Entity framework eu utilizo ele diretamente em meus controllers.

    Dificilmente você vai reaproveitar uma consulta para justificar o padrão Repository, as vezes você precisa usar um Include, ou algo assim para buscar outra coluna. 

    segunda-feira, 20 de agosto de 2012 14:14
  • Ola amigos, bom dia!  Após um tempo estudando a arquitetura MVC e o Entity framework, voltei aqui para responder a minha própria duvida. :)

    A resposta para ela é simples, vamos la:

    • Tudo está completamente ligado. A POCO ela vai ter utilidade para você retirar as classes de mapeamento de objeto(classes de transferencia) do edmx, mas só vi necessidade de fazer isso caso você queira alterar alguma propriedade da mesma.  EX - Tem um campo IDADE e quero colocar uma regra de idade no SET do do mesmo, sem o POCO eu posso fazer isso normalmente, acho a propriedade mapeada no codigo do edmx e aplico o que eu quero, porem quando eu atualizar o edmx isso vai ser perdido pois ele vai alterar todas as classes e propriedades gerando elas tudo novamente. Já com o POCO você não vai se preocupar com isso pois as suas classes de mapeamento de objeto vão ficar separadas. POCO = DTO .. rsrs  

    • Não vejo necessidade de usar Repository a não ser se desacoplar o seu modo de acesso a dados do resto mas isso fica legal se desacoplar as Dependências. A ideia do repository é criar uma camada de abstração acima da camada de acesso a dados(Cria uma porrada de interfaces e desacopla como vai ser acessado os dados, pois vai estar tudo em interface, as BusinessRules vão utilizar as interfaces e vai ter um metodo que vai "INJETAR", vai preencher essa interface com o Repositório que você precisa....) EX - Tenho um Repositorio de CLIENTE para MYSQL e otro para SQL.... Para a minha classe de Negocio(BusinessRules) vai ser independente qual eu vou usar, pois la vai estar implementando as interfaces em comum com os 2 repositorios, o que vai distinguir se eu vou usar SQL ou MYSQL vai ser o metodo que vai INJETAR,IMPLEMENTAR, CRIAR essa interface para mim.... vai ter um lugar la que vai ter uma condição(SE FOR ISSO, CRIA REPOSITORIO SQL, SE FOR AQUILO CRIA O REPOSITORIO MYSQL). 

    Lembrando que isso não vai desacoplar o seu projeto da camada de acesso a dados, pois se sua camada de acesso a dados usa o EF, você vai ter que ter as dependencias do EF acoplado em todos os projetos que utilizam essa forma de acesso a dados... para evitar isso você aplica o Dependency Injection(Pesquisem por Ninject ou UNITY). PS - Prefiro o NInject.

    Obrigado a todos que tentaram me ajudar, mas essa é a resposta... No final de tudo a conclusão é: Use o que for melhor para você. +D

    quinta-feira, 22 de novembro de 2012 12:24
  • O padrão Repository surgiu com o DDD(Domain Driven Design), o objetivo do mesmo não é desacoplar, mas sim ser um Repositório de Objetos de Dominio. No caso do Entity Framework, ele já é o Repositorio, ele mantém coleções de objetos. Caso você queira utilizar vários bancos de dados você vai apenas estar colocando uma camada de abstração em seu repositório existente, ou seja ele já existe, o que é feito é acrescentar uma camada. 

    POCO(Plain Old Clr Object) é a forma comum de se representar os objetos do Dominio. POCO é apenas uma definição para uma classe que contém apenas objetos simples.

    DTO(Data Transfer Object) sua única função é transportar dados, então nem todo POCO é DTO.

    quinta-feira, 22 de novembro de 2012 13:20