In fact, só prá constar, eu achei o artigo muito legal.
Só quis mostrar aos leitores que existem opções decentes e suportadas pela própria Microsoft, com evolução a pleno vapor e tendo cada vez mais ascenção no roadmap do .NET Framework (como parte integrante do mesmo e não apenas como módulos a serem instalados).
Este é um conceito que ficou deixado de lado pela comunidade .NET (apesar da utilização do NHibernate ter side razoavelmente difundida no passado) por um certo tempo e os poucos frameworks que existiam/existem para isso em .NET nem sempre foram tão bem suportados quanto são na comunidade java (ou pelo menos não tão fáceis de usar quanto o restante dos frameworks e building blocks disponibilizados pelos times de Patterns & Practices).
Hoje, além de termos as plataformas para ORM built-in no próprio .NET framework a partir da versão 3.0 e agora muitoooo bons na 4.0, ainda temos frameworks de repseito desenvolvidos por terceiros baseados em DSL e inclusive fully integrated ao visual studio 2010.
Um ótimo exemplo é o Telerik que é muito bem conceituado
Grande abraço cara e espero ter contribuido um pouco.
PS: Sei que a coluna é do dicas-l mas vale a pena ressaltar que não estou defendendo uma plataforma contra a outra.
É apenas um informativo para outros leitores da coluna que assim como eu se utilizam dela para aprender mais e conhecer o outro lado da laranja.
.NET é free. Pago são as ferramentas de desenvolvimento, mas o leitor pode usar opções free para isso, inclusive rodando sobre linux (Mono framework com Sharp developer).
Entendendo os conceitos sobre mapeamento objeto/relacional
Colaboração: Dr. Spock
Data de Publicação: 15 de Março de 2010
Como existem diferenças conceituais entre o modelo relacional usados pelos bancos de dados e a orientação a objetos, acabou surgindo a técnica de mapeamento objeto-relacional (ORM). Esta técnica sugere como devemos persistir o estado de um objeto (atributos, relacionamentos e herança) em tabelas de banco de dados relacional (como Oracle, SQL Server, DB2, MySQL, etc). Diversas plataformas e linguagens promovem esta técnica através de frameworks. Na plataforma Java existe o consagrado framework Hibernate e agora um padrão chamado JPA. Já na plataforma .NET também podemos encontrar o NHibernate (um porte do Hibernate para .NET), o Microsoft s ObjectSpaces e LINQ, dentre outros.
Compreender os conceitos da técnica ORM é o primeiro passo para usar efetivamente os frameworks disponíveis na plataforma. Os dois primeiros artigos citados nas referências, escrito pelo agilista Scott W. Ambler, descrevem minuciodamente esta técnica, além de discutir o gap conceitual entre o modelo relacional e a orientação a objetos.
Muitos criticam o uso de um framework como o Hibernate ao intermediar a persistência dos objetos alegando perda de performance, uma camada desnecessária a mais na aplicação, a falta de controle nos SQLs gerados e a preferencia por executar as velhas e tradicionais instruções SQL diretamente. Contudo, muitas destas críticas resultam de uso inadequado dos framework pela simples falta de conhecimento dos conceitos fundamentais sobre ORM e sobre como o framework funciona.
Mas muitas informações estão disponíveis na rede, empresas realizam consultoria neste assunto, além de tutoriais e cursos gratuitos (veja um exemplo em: Introducao ao Hibernate).
Referências
- Mapping Objects to Relational Databases: O/R Mapping In Detail - By Scott Ambler
- The Object-Relational Impedance Mismatch - By Scott Ambler
- Mini-curso gratuito sobre ORM e Hibernate
- Hibernate ORM Framework for Java
- NHibernate - Hibernate ORM Framework for .NET
- Object-Relational Persistence for .NET - By Scott Bellware
- Introducing LINQ to Relational Data
- A First Look at ObjectSpaces in Visual Studio 2005
Sobre o autor: Dr. Spock, as vezes também conhecido como Alberto Lemos, trabalha há mais de 10 anos no desenvolvimento de soluções para internet e Java. Formado em Física pela UFV em Viçosa, Já participou do desenvolvimento de dezenas de sistemas corporativos, realizando atividades desde o levantamento de requisitos, modelagem UML, definição de arquitetura, implementação, testes e otimização de aplicações. Com experiência em consultoria e ensino de informática, especializa-se em técnicas da orientação a objetos com foco na arquitetura de sistemas. Acumula mais de 1200 horas ministrando treinamento nas carreiras Globalcode, além de palestras e tutorais nos principais eventos nacionais e internacionais.
Veja a relação completa dos artigos da Bancos de Dados Livres
Para se manter atualizado sobre as novidades desta coluna, consulte sempre o newsfeed RSS
Para saber mais sobre RSS, leia o artigo O Padrão RSS - A luz no fim do túnel.
Opinião dos Leitores
Gustavo Velasquez
16 Mar 2010, 20:57
16 Mar 2010, 20:57
Gustavo Velasquez
16 Mar 2010, 20:43
16 Mar 2010, 20:43
É isso ai Dr Spock. A idéia é essa mesmo e concordo em gênero número e grau.
Só dei a contribuição para mostrar as opções "do outro lado da ponte" (I mean, soluções Microsoft para ORM).
Grande abraço e continue com as dicas sobre assuntos interessantes e que causam polêmica como este.
Parabéns,
Gustavo.
Só dei a contribuição para mostrar as opções "do outro lado da ponte" (I mean, soluções Microsoft para ORM).
Grande abraço e continue com as dicas sobre assuntos interessantes e que causam polêmica como este.
Parabéns,
Gustavo.
Dr. Spock
16 Mar 2010, 19:19
16 Mar 2010, 19:19
Olá Anderson e Gustavo,
Obrigado pelos comentários e complementos!
Eu sempre parto do pressuposto de que não existe uma solução para todos os problemas (silver bullet) e uma única solução para um problema específico. Sempre defendo a ideia da solução certa para o problema considerando o princípio KISS. Contudo, encontrar uma solução tão simples quanto possível para problemas complexos pode ser difícil ou exigir soluções com um certo grau de complexidade.
Mas, sei que temos muitas soluções de tamanhos diferentes para problemas de tamanho diferentes. Por isso, concordo com vocês que em *muitas* situações o Hibernate não é o caminho. Mas, quando é o caminho, deve-se saber usar a tecnologia efetivamente. Aí que está o problema dentro de muitas empresas sob pressão dos prazos e equipes com pouca experiência em favor dos custos reduzidos e em detrimento da qualidade. Por isso, mesmo o uso de SQL puramente não sendo um argumento, muitos usam como argumento, principalmente porque dominam muito bem esta tecnologia e aplicando em "ad hoc" a ideia do "para martelo tudo é cabeça de prego!". Incorrendo num erro por achar que todos os problemas são resolvidos com a mesma solução.
Por outro lado, para um texto simples e curto como o que foi sugerido, temos que apresentar apenas um ponto de vista, uma possível solução dentre às várias disponíveis.
De qualquer maneira, viva a diversidade, já que temos muitas linguagens, ferramentas, plataformas e soluções!
Obrigado pelas contribuições!
By Spock
http://blog.spock.com.br/
http://twitter.spock.com.br/
http://www.springbrasil.com.br/
Obrigado pelos comentários e complementos!
Eu sempre parto do pressuposto de que não existe uma solução para todos os problemas (silver bullet) e uma única solução para um problema específico. Sempre defendo a ideia da solução certa para o problema considerando o princípio KISS. Contudo, encontrar uma solução tão simples quanto possível para problemas complexos pode ser difícil ou exigir soluções com um certo grau de complexidade.
Mas, sei que temos muitas soluções de tamanhos diferentes para problemas de tamanho diferentes. Por isso, concordo com vocês que em *muitas* situações o Hibernate não é o caminho. Mas, quando é o caminho, deve-se saber usar a tecnologia efetivamente. Aí que está o problema dentro de muitas empresas sob pressão dos prazos e equipes com pouca experiência em favor dos custos reduzidos e em detrimento da qualidade. Por isso, mesmo o uso de SQL puramente não sendo um argumento, muitos usam como argumento, principalmente porque dominam muito bem esta tecnologia e aplicando em "ad hoc" a ideia do "para martelo tudo é cabeça de prego!". Incorrendo num erro por achar que todos os problemas são resolvidos com a mesma solução.
Por outro lado, para um texto simples e curto como o que foi sugerido, temos que apresentar apenas um ponto de vista, uma possível solução dentre às várias disponíveis.
De qualquer maneira, viva a diversidade, já que temos muitas linguagens, ferramentas, plataformas e soluções!
Obrigado pelas contribuições!
By Spock
http://blog.spock.com.br/
http://twitter.spock.com.br/
http://www.springbrasil.com.br/
Gustavo Velasquez
16 Mar 2010, 10:46
16 Mar 2010, 10:46
E ai Spock, blz ?
Dicas para o pessoal Microsoft (e para os de java que são curiosos tb).
Eu acresentaria informações a respeito do ADO.NET Entity Framework e Domain Services na plataforma .NET, já que LINQ na verdade é uma sub-linguagem para consultas não importa a fonte de dados: ela é um subset do conceito ORM, usado para abstrair o conceito de consultas, porém estas consultas podem ser executadas sobre uma ampla gama de sources tais como Objetos, arquivos XML, Entidades (ai entra a parte ORM) e SQL itself.
Estes são recentes avanços que indicam que a utilização de frameworks ORM está mesmo em alta.
É claro que há cenários em que uma camada a mais, por mais simples que seja vai gerar desconfiança e buzz.
Em alguns csaos por parte do time quando há falta de conhecimento/confiança no próprio taco /vontade de aprender e por conceitos na balança para justificar a posição de utilizá-los ou não.
As vezes o problema vem do alto - dos sponsors que temem por perda de performance/manutenabilidade do código/dominio sobre o que está sendo executado/achar profissionais competentes naquela prática, etc.
Na minha opinião, a maior parte dos casos é pura e simplesmente uma questão de gosto por parte do pessoal de DEV (e que nem sempre vem acompanhada de justificativas fundamentadas em fatos ou experimentos).
Cabe ao arquiteto definir se o cenário enfrentado, prazo, escopo do projeto suporta certo nível de "massagem de ego" no time ou se precisamos de um pouco mais de ditadura e definição precisa da técnica a ser usada, descartando se o sentimento de conforto de uns "trabalhando menos" na escovação de bits e mais no negócio e outros "tendo o controle " em suas mãos sendo isso necessário ou não.
Bom este assunto dá discussões frenéticas em blogs e é muito legal de explorar. todo mundo sai ganhando.
Abraço cara.
Overview sobre ADO.NET Entity Framework.
http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx
Performance Considerations:
http://msdn.microsoft.com/en-us/library/cc853327.aspx
Gustavo Velasquez
Dicas para o pessoal Microsoft (e para os de java que são curiosos tb).
Eu acresentaria informações a respeito do ADO.NET Entity Framework e Domain Services na plataforma .NET, já que LINQ na verdade é uma sub-linguagem para consultas não importa a fonte de dados: ela é um subset do conceito ORM, usado para abstrair o conceito de consultas, porém estas consultas podem ser executadas sobre uma ampla gama de sources tais como Objetos, arquivos XML, Entidades (ai entra a parte ORM) e SQL itself.
Estes são recentes avanços que indicam que a utilização de frameworks ORM está mesmo em alta.
É claro que há cenários em que uma camada a mais, por mais simples que seja vai gerar desconfiança e buzz.
Em alguns csaos por parte do time quando há falta de conhecimento/confiança no próprio taco /vontade de aprender e por conceitos na balança para justificar a posição de utilizá-los ou não.
As vezes o problema vem do alto - dos sponsors que temem por perda de performance/manutenabilidade do código/dominio sobre o que está sendo executado/achar profissionais competentes naquela prática, etc.
Na minha opinião, a maior parte dos casos é pura e simplesmente uma questão de gosto por parte do pessoal de DEV (e que nem sempre vem acompanhada de justificativas fundamentadas em fatos ou experimentos).
Cabe ao arquiteto definir se o cenário enfrentado, prazo, escopo do projeto suporta certo nível de "massagem de ego" no time ou se precisamos de um pouco mais de ditadura e definição precisa da técnica a ser usada, descartando se o sentimento de conforto de uns "trabalhando menos" na escovação de bits e mais no negócio e outros "tendo o controle " em suas mãos sendo isso necessário ou não.
Bom este assunto dá discussões frenéticas em blogs e é muito legal de explorar. todo mundo sai ganhando.
Abraço cara.
Overview sobre ADO.NET Entity Framework.
http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx
Performance Considerations:
http://msdn.microsoft.com/en-us/library/cc853327.aspx
Gustavo Velasquez
Anderson Marques Ferraz
15 Mar 2010, 17:34
15 Mar 2010, 17:34
Ah, sim, mas eu gostei do artigo! Obrigado pelas links sugeridos.
Anderson Marques Ferraz
15 Mar 2010, 16:56
15 Mar 2010, 16:56
"Muitos criticam o uso de um framework como o Hibernate ao intermediar a persistência dos objetos alegando perda de performance, uma camada desnecessária a mais na aplicação, a falta de controle nos SQLs gerados e a preferencia por executar as velhas e tradicionais instruções SQL diretamente. Contudo, muitas destas críticas resultam de uso inadequado dos framework pela simples falta de conhecimento dos conceitos fundamentais sobre ORM e sobre como o framework funciona."
"It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail"
"perda de performance"
Olha, se você introduz mais uma camada, o desempenho cai. Minimamente que seja, nada fica mais rápido se você tem mais um intermediário.
"uma camada desnecessária"
ORM será sempre útil e necessário? Qual o tamanho do seu projeto?
"preferencia por executar as velhas e tradicionais instruções SQL"
Velhas e tradicionais? Isso não constitui um argumento.
Em suma, o que eu quero dizer é que, pro seu projeto, pode não ser interessante utilizar uma camada grande como um framework ORM do porte do Hibernate.
"It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail"
"perda de performance"
Olha, se você introduz mais uma camada, o desempenho cai. Minimamente que seja, nada fica mais rápido se você tem mais um intermediário.
"uma camada desnecessária"
ORM será sempre útil e necessário? Qual o tamanho do seu projeto?
"preferencia por executar as velhas e tradicionais instruções SQL"
Velhas e tradicionais? Isso não constitui um argumento.
Em suma, o que eu quero dizer é que, pro seu projeto, pode não ser interessante utilizar uma camada grande como um framework ORM do porte do Hibernate.
Powered by Scriptsmill Comments Script
