NHibernate x LINQ
Meu atual código está baseado em no módulo tabela (apoiado em Datasets), fato que impede a boa utilização de padrões.
Tenho estudado muito sobre Design Patterns, Arquitetura de Software e OOP.
Pois bem, para utilizar programação OOP plenamente, no meu entender, a utilização Domain Model é a melhor opção.Resumindo: Vou refatorar toda minha framework.
O ponto que gostaria de levantar é o seguinte:
É aconsalhável iniciar a refatoração agora utilizando NHibernate como ORM ou aguardar o LINQ?
Por favor justifiquem a resposta.
Obrigado
Respostas
Oi !
Primeiro problema :
Você escreveu - "para utilizar programação OOP plenamente"
OOP não é um fim, é um meio. Você usa se precisar, quando precisar. Se você não conseguir justificar a aplicação de uma característica da OOP ou um determinado pattern sem recorrer a frases feitas de livros escritos por fanáticos em OOP, então simplesmente esqueça e não aplique.
Assista ao vídeo em http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032341962&Culture=pt-BR
Tenho certeza de que vai achar bem interessante.
Quanto a pergunta em questão : Aguarde o Linq. Se começar isso agora com NHibernate quando terminar já vai estar legado.
Mas se estiver no Rio, não deixe de assistir a um evento que faremos sobre o Linq, muito em breve (ainda não está marcado). O palestrante, que se especializou em Linq, fez uma comparação do mapeamento objeto/relacional com Linq e do acesso tradicional a dados e identificou 800% de diferença de performance a favor do acesso tradicional. Porém a partir disso criou uma solução para viabilizar o uso do Linq.
[]'s
Meu Blog : http://blog.dennestorres.com.br
Flávio,
Na minha opinião, já que você tem estudado Patterns e pretende fazer refatoring da sua aplicação, crie uma camada de acesso à dados com baixo acoplamento, coisa que você consegue utilizando padrões conhecidos como o DAO, Repository.
Assim, você pode escolher qualquer Framework para acessar os dados, e se depois você quiser trocar, o impacto na sua aplicação será baixo.
Outro detalhe, a utilização de DataSets, DataReaders e acesso via Stored Procedures não quer dizer que sua aplicação não utilize padrões, acho importante antes de tomar a decisão da utilizar de um framework ORM, você colocar na balança os prós e contras de cada Framework.
Esse link talvez possa ajudar com relação aos padrões:
http://msdn2.microsoft.com/en-us/library/ms954595.aspx
Agora quanto a escolha, eu acho o NHibernate é um Framework mais maduro, pois seu desenvolvimento foi baseado em um Framework muito utilizado e melhorado (Hibernate), porém eu acho importante que antes de utilizar, a equipe tenha uma certa cultura de utilzação de Frameworks Open Source, caso não tenha (ou não queira ter rsrs), acho melhor esperar o LINQ ou utilizar o modelo tradicional mesmo (Stored Procedures).
Espero ter contribuídoFlávio,
veja também esse artigo:
Comparing LINQ and Its Contemporaries - http://msdn2.microsoft.com/en-us/library/Aa479863.aspx
Ricardo Oneda
http://oneda.mvps.org/blogE, finalmente, o único ponto que faltou para completar as respostas anteriores:
LINQ não tem absolutamente nada a ver com ORM. Logo, ele não é concorrente do NHibernate. Mas não se preocupe, essa confusão é bastante comum.
Se você quiser realmente traçar um paralelo entre o LINQ e o NHibernate, o LINQ é um concorrente do HQL (Hibernate Query Language), não do NHibernate. Na verdade, do ponto de vista técnico é perfeitamente plausível termos um LINQ for NHibernate (e não me surpreenderia se alguém já não estivesse fazendo isso).
Quanto a um framework de ORM da Microsoft, a alternativa chama-se ADO.NET Entities - este sim, concorrente do NHibernate.
Esta confusão é realmente comum. A Microsoft está investindo em duas soluções de ORM. Uma delas, para problemas mais simples e projetos no qual o esquema de banco de dados será criado junto com a aplicação, que é o LINQ to SQL.
O blog do ScottGu tem vários exemplos para LINQ to SQL:
http://weblogs.asp.net/scottgu/search.aspx?q=linq+to+sql&o=Relevance
O outro é o Entity Framework, que se propõe a resolver problemas mais complexos, acessos a base de dados legadas, etc. Recentemente foi publicado um CTP deste framework:
Neste blog você também poderá acompanhar a sua evolução.
PS: Não posso deixar de comentar uma questão. Quando você diz que vai refactorar todo o seu framework, isto quer dizer que vc tem testes automatizados para ele? Ou que ele não está em produção ainda? Me dá calafrio só de escutar algo asim ...
Eduardo Miranda
www.eduardomiranda.net/blogs/dotnet/
Todas as Respostas
Oi !
Primeiro problema :
Você escreveu - "para utilizar programação OOP plenamente"
OOP não é um fim, é um meio. Você usa se precisar, quando precisar. Se você não conseguir justificar a aplicação de uma característica da OOP ou um determinado pattern sem recorrer a frases feitas de livros escritos por fanáticos em OOP, então simplesmente esqueça e não aplique.
Assista ao vídeo em http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032341962&Culture=pt-BR
Tenho certeza de que vai achar bem interessante.
Quanto a pergunta em questão : Aguarde o Linq. Se começar isso agora com NHibernate quando terminar já vai estar legado.
Mas se estiver no Rio, não deixe de assistir a um evento que faremos sobre o Linq, muito em breve (ainda não está marcado). O palestrante, que se especializou em Linq, fez uma comparação do mapeamento objeto/relacional com Linq e do acesso tradicional a dados e identificou 800% de diferença de performance a favor do acesso tradicional. Porém a partir disso criou uma solução para viabilizar o uso do Linq.
[]'s
Meu Blog : http://blog.dennestorres.com.br
Flávio,
Na minha opinião, já que você tem estudado Patterns e pretende fazer refatoring da sua aplicação, crie uma camada de acesso à dados com baixo acoplamento, coisa que você consegue utilizando padrões conhecidos como o DAO, Repository.
Assim, você pode escolher qualquer Framework para acessar os dados, e se depois você quiser trocar, o impacto na sua aplicação será baixo.
Outro detalhe, a utilização de DataSets, DataReaders e acesso via Stored Procedures não quer dizer que sua aplicação não utilize padrões, acho importante antes de tomar a decisão da utilizar de um framework ORM, você colocar na balança os prós e contras de cada Framework.
Esse link talvez possa ajudar com relação aos padrões:
http://msdn2.microsoft.com/en-us/library/ms954595.aspx
Agora quanto a escolha, eu acho o NHibernate é um Framework mais maduro, pois seu desenvolvimento foi baseado em um Framework muito utilizado e melhorado (Hibernate), porém eu acho importante que antes de utilizar, a equipe tenha uma certa cultura de utilzação de Frameworks Open Source, caso não tenha (ou não queira ter rsrs), acho melhor esperar o LINQ ou utilizar o modelo tradicional mesmo (Stored Procedures).
Espero ter contribuídoFlávio,
veja também esse artigo:
Comparing LINQ and Its Contemporaries - http://msdn2.microsoft.com/en-us/library/Aa479863.aspx
Ricardo Oneda
http://oneda.mvps.org/blogPrimeiramente, obrigado pela resposta de todos.
Mas gostaria de ponderar sobre alguns comentários:
Caro Dennes, de fato gostaria de fundamentar meu Framework "OOP plenamente" exatamente porque muito dos meus problemas serão resolvidos com a aplicação de Padrões.A minha opinião sobre Design Patters é que são um "MEIO" de ter menos dor de cabeça com manutenção e expansão funcionais do código. E é essa a minha finalidade.
Caro Fernando, obrigado pelos esclarecimento. A adoção de padrão "DAO" já ponto pacífico aqui na firma. Nossa dúvida a utilização ou não de Mapeador Objeto-Relacional. E caso adotemos, se começamos agora com NHibernate ou esperamos o LINQ.
O artigo que o Ricardo Oneda indicou faz boas ponderações (vou ler com mais calma)
Agora surgiu uma dúvida: Há suporte do LINQ para concorrência pessimista na sessão?
Até agora estamos tendendo em direção ao NHIbernate, mas vamos continuar a estudar a melhor opção.
Um abraço a todos.
E, finalmente, o único ponto que faltou para completar as respostas anteriores:
LINQ não tem absolutamente nada a ver com ORM. Logo, ele não é concorrente do NHibernate. Mas não se preocupe, essa confusão é bastante comum.
Se você quiser realmente traçar um paralelo entre o LINQ e o NHibernate, o LINQ é um concorrente do HQL (Hibernate Query Language), não do NHibernate. Na verdade, do ponto de vista técnico é perfeitamente plausível termos um LINQ for NHibernate (e não me surpreenderia se alguém já não estivesse fazendo isso).
Quanto a um framework de ORM da Microsoft, a alternativa chama-se ADO.NET Entities - este sim, concorrente do NHibernate.
Flávio Facchinetti wrote: Agora surgiu uma dúvida: Há suporte do LINQ para concorrência pessimista na sessão?
Como mencionei anteriormente, LINQ é uma linguagem de query (como SQL, XQuery, HQL etc.); logo, ele não sabe nada a respeito de persistência. Ele só sabe consultar dados.
Esta confusão é realmente comum. A Microsoft está investindo em duas soluções de ORM. Uma delas, para problemas mais simples e projetos no qual o esquema de banco de dados será criado junto com a aplicação, que é o LINQ to SQL.
O blog do ScottGu tem vários exemplos para LINQ to SQL:
http://weblogs.asp.net/scottgu/search.aspx?q=linq+to+sql&o=Relevance
O outro é o Entity Framework, que se propõe a resolver problemas mais complexos, acessos a base de dados legadas, etc. Recentemente foi publicado um CTP deste framework:
Neste blog você também poderá acompanhar a sua evolução.
PS: Não posso deixar de comentar uma questão. Quando você diz que vai refactorar todo o seu framework, isto quer dizer que vc tem testes automatizados para ele? Ou que ele não está em produção ainda? Me dá calafrio só de escutar algo asim ...
Eduardo Miranda
www.eduardomiranda.net/blogs/dotnet/
Igor Abade V. Leite - MVP wrote: Na verdade, do ponto de vista técnico é perfeitamente plausível termos um LINQ for NHibernate (e não me surpreenderia se alguém já não estivesse fazendo isso).
Igor,
parece que alguém já pensou nisso
:
Ricardo Oneda
http://oneda.mvps.org/blogIgor Abade V. Leite - MVP wrote: LINQ não tem absolutamente nada a ver com ORM. Logo, ele não é concorrente do NHibernate. Mas não se preocupe, essa confusão é bastante comum.
Igor, ralvez quando ele se referiu a LINQ, ele não se referia somente a linguagem para consultas, mas também as features que o Visual Studio 2008 nos disponibilizará junto com o LINQ, como por exemplo o Object Relacional Designer.
Acho que esse conjunto de features podemos considerar como um framework ORM, ou não?
Fernando, o exemplo que você deu é perfeito - com ele conseguimos ilustrar a "bagunça" que a Microsoft está fazendo na cabeça das pessoas. :-)
O designer que você mencionou faz parte do LINQ to SQL. Essa solução é composta de duas partes:
-
Uma ferramenta de geração de classes a partir do Object-Relational Designer. Com essa ferramenta podemos gerar classes tipadas a partir de objetos do SQL Server (de forma similar ao DataSet tipado, mas usando objetos e coleções ao invés de DataRows e DataTables. Essas classes podem ser usadas independentemente do LINQ.
-
O provedor LINQ para o SQL Server, que é capaz de gerar queries SQL dinâmicas (e otimizadas) a partir das queries do LINQ. As classes geradas na etapa anterior dão as "pistas" para que o provedor do LINQ to SQL consiga otimizar as queries.
Por aí podemos perceber que a persistência (item 1) e a pesquisa (item 2) são distintas. Mas no dia-a-dia elas tendem a estar tão próximas que a linha que as divide acaba ficando bem fina.
-
Mais uma vez obrigado a todos.
Quando pegamos a documentação do NHibernate temos noção geral da Ferramenta: ORM e Query Language (HQL) e outras funcionalidades.
O LINQ + ADO.NET Entities ainda está bem nebuloso.
Temos pouca experimentação e , logo, pouca documentação.A discussão acima serviu que eu tomasse minha decisão: Vou começar agora a implementar o NHibernate.
Os principais motivos é que a curva de aprendizado é enorme e o tempo de refatoração do código maior ainda.
Assim não vale a pena esperar o LINQ, pois perderia tempo valioso e ainda não há garantias que será uma ferramenta igual ou melhor que NHibernate.Vou acompanhar o lançamento oficial da ferramenta (LINQ) e quando a mesma estiver madura, decidirei se é preferível e viável utilizá-la.
Agradeço a todos pelos comentários e pretendo relatar os resultados quando eu os tiver.
Abraço
