none
Entity Framework - Opinião/Dúvidas RRS feed

  • Pergunta

  • Pessoal, atualmente utilizo o Fluent Nhibernate como ORM.

    Logo crio minhas entidades, crio a classe para mapear essa entidade e o Nhibernate gera o banco para mim...

    Bom, não conheço nada do EF, vi que estão falando bastante da versão 6, e não quero perguntar qual é melhor ou pior, e também vi que no mvc5 ele trás ótimo suporte a controle de usuários via asp.net identity.

    Mas se alguém tiver uma opinião para me dar, "Por que usar EF ao invés do Nhibernate?"

    E tenho umas perguntas básicas sobre o EF:

    Como eu gero meu banco igual faço com o NHibernate?

    Há como criar essas classes de mapeamento assim como crio no Nhibernate?

    Ele suporta outros bancos de dados como postgre, mysql ? há drivers bons opensource ou apenas pagos?

    E se alguém já teve contato com o MVC5, o Asp.net identity trabalha apenas com o sql server?

    Obrigado. E eu pesquisei muito...mas cada um fala uma coisa, então fica difícil sanar essas dúvidas que são básicas.

    quinta-feira, 19 de setembro de 2013 14:57

Respostas

  • Bancos que o EF suporta: http://en.wikipedia.org/wiki/Entity_Framework

    Tópico no DevMedia: http://www.devmedia.com.br/forum/nhibernate-x-entity-framework/446672

    Revista .Net Magazine: http://www.devmedia.com.br/nhibernate-vs-entity-framework-revista-net-magazine-101/26745, pena eu nao conseguir postar o post completo por ser visivel apenas para assinantes. 

    NHibernate, Entity Framework, Incompatibilidades e Provedores de dados

    Apesar dos provedores OLE DB e ODBC do .NET implementarem as interfaces do ADO.NET, o Entity Framework 4 é incompatível com ambas as tecnologias, deste modo, bancos que possuem apenas drivers OLE DB e ODBC não poderão ser acessados via Entity.

    Em contrapartida, o NHibernate utiliza as interfaces do ADO.NET, permitindo o suporte a uma gama maior de fontes de dados, incluindo ODBC e OLE DB. Isto é possível por conta da interface IDriver. Esta interface é utilizada internamente pelo NHibernate para a obtenção de objetos de conexão e comandos de bancos de dados, devendo ser implementada pelo NHibernate Driver (Nota do DevMan 1) do banco de dados a ser utilizado.

    Nota do DevMan 1

    NHibernate Driver é um driver específico para determinados bancos de dados. Os drivers do NHibernate trabalham em sintonia com as interfaces IDbConnection, IDbCommand, IDbDataReader, IDataParameter existentes no ADO.NET, possibilitando a criação de drivers personalizados para qualquer banco de dados que utilize da tecnologia.

    O NHibernate contém suporte nativo a inúmeros SGDBs, porém caso um determinado banco não seja previamente suportado basta que seja implementada esta interface para o banco em questão e o NHibernate irá se conectar ao mesmo.

    Tabela 1 lista os principais SGDBs e se os mesmos são suportados pelo NHibernate e Entity Framework.

    Tabela 1. Relação de bancos de dados e respectivos suportes pelos Frameworks ORM

    Onde:

    · V – Suportado plenamente

    · X – Não suportado

    · P – Suportado parcialmente

    Mapeamento de Propriedades Entity Framework

    Conforme exibido na Listagem 2, o Entity Framework utiliza o namespace System.ComponentModel.DataAnnotations, componente nativo do .NET, fazendo com que tenhamos um mapeamento mais explícito, com atributos mais descritivos. A classe anotada como Table indica explicitamente uma Tabela e as propriedades anotadas com Column são equivalentes às colunas. Veja que o atributo ForeignKey indica claramente propriedades relacionadas a outras tabelas.

    Relações do tipo mestre-detalhe são suportadas por ambos os frameworks, como é o caso da relação entre Cidade e Cliente. Neste tipo de relação o Entity Framework precisa do mapeamento explícito de uma propriedade que remonte à coluna de chave estrangeira e uma propriedade que seja do tipo da tabela estrangeira mapeada. Como exemplo disso temos as propriedades Cidade_Id e Cidade em Cliente, e Cliente_Id e Cliente em Pedido. Além disso, no Entity Framework as propriedades transientes (não persistentes) devem ser explicitamente mapeadas com o atributo NotMapped.

    Na Listagem 3 temos o mapeamento das classes para o NHibernate onde utilizamos o namespace NHibernate.Mapping.Attributes, cuja biblioteca pode ser obtida pelo NuGet. O mapeamento não é tão explícito como no Entity Framework, pois as classes são anotadas como Class indicando uma tabela para a classe, enquanto que as propriedades são anotadas como Property. As relações anotadas como ManyToOne indicam uma relação de uma Foreign Key.

    No NHibernate relações do tipo mestre-detalhe não necessitam do mapeamento de uma propriedade extra, sendo suficiente a propriedade relacionada, indicando a coluna que contém a chave estrangeira. Por outro lado, no NH as propriedades transientes não são mapeadas, logo não precisam ser decoradas, como é o caso da propriedade CepValido (linha 38) da classe Cliente.

    Propriedades personalizadas – NHibernate x Entity Framework

    Algumas vezes é importante termos campos pré-calculados por uma sub-consulta SQL em uma determinada entidade para que possamos agilizar algumas tarefas com a entidade. Um exemplo disso é se precisássemos saber quando foi a última data do pedido de um determinado cliente, onde poderíamos ter uma simples consulta para recuperar esta informação.

    O Entity Framework não suporta este tipo de mapeamento e, por esta razão, ignoramos esta propriedade na classe cliente mapeada para o mesmo.

    Já o NHibernate suporta este tipo de mapeamento de forma bastante simplificada. Veja que utilizamos uma consulta direta ao banco de dados. As tabelas e colunas utilizadas na consulta devem ter os nomes iguais ao banco, porém o parâmetro utilizado no filtro pode ser uma das propriedades da classe, como é o caso da propriedade Id passada como parâmetro de consulta na cláusula “where”, como podemos observar na linha 36 da Listagem 3.


    Conclusão

    No estudo apresentado, ficou fora de questão a realização de comparativos de desempenho entre as ferramentas por uma única questão: aplicações de acesso a dados que necessitam de máximo desempenho no acesso a dados devem ser construídas com ADO.NET, mais especificamente focadas para um determinado banco de dados. Pois frameworks de persistência servem como facilitadores de acesso a dados e possuem desempenho de acesso a dados inferior a soluções que usem ADO.NET de forma direta.

    No quesito versatilidade tanto o NHibernate como o Entity Framework se saem bem para a maioria das aplicações. Além do que o código gerado é bastante limpo e legível para futuras manutenções.

    É também perceptível que ambos compartilham muitas semelhanças em diversos escopos, como a criação de sessão e a manipulação de resultados

    Qual o melhor dentre estes frameworks?

    Esta pergunta não pode ser respondida sem um devido contexto, pois o Entity Framework apesar do seu princípio atordoado se provou uma ferramenta bastante sólida, confiável e com suporte de ninguém menos do que a Microsoft enquanto que o NHibernate, como importação do bem sucedido projeto advindo do Java, tem uma adoção cada vez maior em comunidades de desenvolvimento por todo o mundo, o que faz com que o mesmo tenha muito conteúdo de ajuda na maioria dos fóruns disponíveis na Web.

    Por outro lado, analisando o quesito bancos de dados suportados o NHibernate é sem dúvida a melhor opção, uma vez que ele se prova bastante versátil, ao passo que o Entity Framework depende de uma implementação por parte do fabricante do banco de dados através de um provedor .NET.

    No contexto de facilidade de desenvolvimento, o Entity Framework se provou ser mais forte do que o NHibernate uma vez que exceções lançadas pelo Entity Framework são bem mais amigáveis do que no NHibernate, bem como a existência dos assistentes de criação já integrados com o próprio Visual Studio.

    Se o desenvolvedor estiver desenvolvendo soluções com bancos de dados Microsoft e pretende adotar programação em Linq, recomendo a utilização do Entity Framework. Em contrapartida, se houver a necessidade da aplicação acessar bases de dados de outros distribuidores, aconselho a utilização do NHibernate.

    Também não podemos deixar de mencionar que, por ser de fonte aberta e com total integração com o log4net, o NHibernate possibilitará aos desenvolvedores avançados um maior controle de integração da ferramenta com o banco de dados, contando com um sistema de log para cada atividade interna do framework.

    Porém é muito importante mencionar o fato de que ambas as ferramentas são bastante parecidas, podendo ser utilizadas para resolver a maioria dos problemas ligados a acesso a dados. Sendo assim, dependerá do desenvolvedor e do contexto do projeto, a decisão de qual ferramenta utilizar.

    Referências

    - Hollerith, Herman: The Forgotten Giant of Information Processing, Áustria, 1982, Editora Columbia;

    - Silberchatz, Abraham: Sistemas de Banco de Dados, EUA, 1995, Editora Elsevier.

    Links

    Projeto Hibernate
    http://www.hibernate.org/

    Projeto NHibernate
    http://nhforge.org/

    ADO.NET Entity Framework
    http://msdn.microsoft.com/pt-br/data/ef.aspx



    Cara, peguei alguns tópicos para você dar uma lida. Ou vai resolver seu problema ou você vai ficar com mais dúvidas ainda. rs.

    Espero ter ajudado.

    Caso ajudou marque. 

    Abraço.


    Good Luck, Fernando Mamprin

    • Marcado como Resposta RodrigoCez sexta-feira, 20 de setembro de 2013 11:58
    quinta-feira, 19 de setembro de 2013 17:58

Todas as Respostas

  • Bancos que o EF suporta: http://en.wikipedia.org/wiki/Entity_Framework

    Tópico no DevMedia: http://www.devmedia.com.br/forum/nhibernate-x-entity-framework/446672

    Revista .Net Magazine: http://www.devmedia.com.br/nhibernate-vs-entity-framework-revista-net-magazine-101/26745, pena eu nao conseguir postar o post completo por ser visivel apenas para assinantes. 

    NHibernate, Entity Framework, Incompatibilidades e Provedores de dados

    Apesar dos provedores OLE DB e ODBC do .NET implementarem as interfaces do ADO.NET, o Entity Framework 4 é incompatível com ambas as tecnologias, deste modo, bancos que possuem apenas drivers OLE DB e ODBC não poderão ser acessados via Entity.

    Em contrapartida, o NHibernate utiliza as interfaces do ADO.NET, permitindo o suporte a uma gama maior de fontes de dados, incluindo ODBC e OLE DB. Isto é possível por conta da interface IDriver. Esta interface é utilizada internamente pelo NHibernate para a obtenção de objetos de conexão e comandos de bancos de dados, devendo ser implementada pelo NHibernate Driver (Nota do DevMan 1) do banco de dados a ser utilizado.

    Nota do DevMan 1

    NHibernate Driver é um driver específico para determinados bancos de dados. Os drivers do NHibernate trabalham em sintonia com as interfaces IDbConnection, IDbCommand, IDbDataReader, IDataParameter existentes no ADO.NET, possibilitando a criação de drivers personalizados para qualquer banco de dados que utilize da tecnologia.

    O NHibernate contém suporte nativo a inúmeros SGDBs, porém caso um determinado banco não seja previamente suportado basta que seja implementada esta interface para o banco em questão e o NHibernate irá se conectar ao mesmo.

    Tabela 1 lista os principais SGDBs e se os mesmos são suportados pelo NHibernate e Entity Framework.

    Tabela 1. Relação de bancos de dados e respectivos suportes pelos Frameworks ORM

    Onde:

    · V – Suportado plenamente

    · X – Não suportado

    · P – Suportado parcialmente

    Mapeamento de Propriedades Entity Framework

    Conforme exibido na Listagem 2, o Entity Framework utiliza o namespace System.ComponentModel.DataAnnotations, componente nativo do .NET, fazendo com que tenhamos um mapeamento mais explícito, com atributos mais descritivos. A classe anotada como Table indica explicitamente uma Tabela e as propriedades anotadas com Column são equivalentes às colunas. Veja que o atributo ForeignKey indica claramente propriedades relacionadas a outras tabelas.

    Relações do tipo mestre-detalhe são suportadas por ambos os frameworks, como é o caso da relação entre Cidade e Cliente. Neste tipo de relação o Entity Framework precisa do mapeamento explícito de uma propriedade que remonte à coluna de chave estrangeira e uma propriedade que seja do tipo da tabela estrangeira mapeada. Como exemplo disso temos as propriedades Cidade_Id e Cidade em Cliente, e Cliente_Id e Cliente em Pedido. Além disso, no Entity Framework as propriedades transientes (não persistentes) devem ser explicitamente mapeadas com o atributo NotMapped.

    Na Listagem 3 temos o mapeamento das classes para o NHibernate onde utilizamos o namespace NHibernate.Mapping.Attributes, cuja biblioteca pode ser obtida pelo NuGet. O mapeamento não é tão explícito como no Entity Framework, pois as classes são anotadas como Class indicando uma tabela para a classe, enquanto que as propriedades são anotadas como Property. As relações anotadas como ManyToOne indicam uma relação de uma Foreign Key.

    No NHibernate relações do tipo mestre-detalhe não necessitam do mapeamento de uma propriedade extra, sendo suficiente a propriedade relacionada, indicando a coluna que contém a chave estrangeira. Por outro lado, no NH as propriedades transientes não são mapeadas, logo não precisam ser decoradas, como é o caso da propriedade CepValido (linha 38) da classe Cliente.

    Propriedades personalizadas – NHibernate x Entity Framework

    Algumas vezes é importante termos campos pré-calculados por uma sub-consulta SQL em uma determinada entidade para que possamos agilizar algumas tarefas com a entidade. Um exemplo disso é se precisássemos saber quando foi a última data do pedido de um determinado cliente, onde poderíamos ter uma simples consulta para recuperar esta informação.

    O Entity Framework não suporta este tipo de mapeamento e, por esta razão, ignoramos esta propriedade na classe cliente mapeada para o mesmo.

    Já o NHibernate suporta este tipo de mapeamento de forma bastante simplificada. Veja que utilizamos uma consulta direta ao banco de dados. As tabelas e colunas utilizadas na consulta devem ter os nomes iguais ao banco, porém o parâmetro utilizado no filtro pode ser uma das propriedades da classe, como é o caso da propriedade Id passada como parâmetro de consulta na cláusula “where”, como podemos observar na linha 36 da Listagem 3.


    Conclusão

    No estudo apresentado, ficou fora de questão a realização de comparativos de desempenho entre as ferramentas por uma única questão: aplicações de acesso a dados que necessitam de máximo desempenho no acesso a dados devem ser construídas com ADO.NET, mais especificamente focadas para um determinado banco de dados. Pois frameworks de persistência servem como facilitadores de acesso a dados e possuem desempenho de acesso a dados inferior a soluções que usem ADO.NET de forma direta.

    No quesito versatilidade tanto o NHibernate como o Entity Framework se saem bem para a maioria das aplicações. Além do que o código gerado é bastante limpo e legível para futuras manutenções.

    É também perceptível que ambos compartilham muitas semelhanças em diversos escopos, como a criação de sessão e a manipulação de resultados

    Qual o melhor dentre estes frameworks?

    Esta pergunta não pode ser respondida sem um devido contexto, pois o Entity Framework apesar do seu princípio atordoado se provou uma ferramenta bastante sólida, confiável e com suporte de ninguém menos do que a Microsoft enquanto que o NHibernate, como importação do bem sucedido projeto advindo do Java, tem uma adoção cada vez maior em comunidades de desenvolvimento por todo o mundo, o que faz com que o mesmo tenha muito conteúdo de ajuda na maioria dos fóruns disponíveis na Web.

    Por outro lado, analisando o quesito bancos de dados suportados o NHibernate é sem dúvida a melhor opção, uma vez que ele se prova bastante versátil, ao passo que o Entity Framework depende de uma implementação por parte do fabricante do banco de dados através de um provedor .NET.

    No contexto de facilidade de desenvolvimento, o Entity Framework se provou ser mais forte do que o NHibernate uma vez que exceções lançadas pelo Entity Framework são bem mais amigáveis do que no NHibernate, bem como a existência dos assistentes de criação já integrados com o próprio Visual Studio.

    Se o desenvolvedor estiver desenvolvendo soluções com bancos de dados Microsoft e pretende adotar programação em Linq, recomendo a utilização do Entity Framework. Em contrapartida, se houver a necessidade da aplicação acessar bases de dados de outros distribuidores, aconselho a utilização do NHibernate.

    Também não podemos deixar de mencionar que, por ser de fonte aberta e com total integração com o log4net, o NHibernate possibilitará aos desenvolvedores avançados um maior controle de integração da ferramenta com o banco de dados, contando com um sistema de log para cada atividade interna do framework.

    Porém é muito importante mencionar o fato de que ambas as ferramentas são bastante parecidas, podendo ser utilizadas para resolver a maioria dos problemas ligados a acesso a dados. Sendo assim, dependerá do desenvolvedor e do contexto do projeto, a decisão de qual ferramenta utilizar.

    Referências

    - Hollerith, Herman: The Forgotten Giant of Information Processing, Áustria, 1982, Editora Columbia;

    - Silberchatz, Abraham: Sistemas de Banco de Dados, EUA, 1995, Editora Elsevier.

    Links

    Projeto Hibernate
    http://www.hibernate.org/

    Projeto NHibernate
    http://nhforge.org/

    ADO.NET Entity Framework
    http://msdn.microsoft.com/pt-br/data/ef.aspx



    Cara, peguei alguns tópicos para você dar uma lida. Ou vai resolver seu problema ou você vai ficar com mais dúvidas ainda. rs.

    Espero ter ajudado.

    Caso ajudou marque. 

    Abraço.


    Good Luck, Fernando Mamprin

    • Marcado como Resposta RodrigoCez sexta-feira, 20 de setembro de 2013 11:58
    quinta-feira, 19 de setembro de 2013 17:58
  • Na minha opinião o EF é mais fácil de trabalhar
    quinta-feira, 19 de setembro de 2013 20:46