Eu tenho uma base de dados em Firebird, e estou em dúvida se devo ou não usar um ORM para facilitar o andamento e aumentar a produtividade de projeto web aqui da empresa, ao invés de usar uma classe (DAO) com métodos diretos de conexão, de consulta e de execução, fazendo tudo na mão e do zero.
Eu estou querendo usar um ORM: eu sei que o mesmo faz muitas coisas que eu teria que escrever do zero, sei que o mesmo pode até ajudar na escalabilidade da aplicação em relação a algumas consultas e sei que um ORM pode ajudar a diminuir o débito técnico.
A questão é que o meu gerente de projeto não concorda com esse ponto de vista, e simplesmente diz que não vale a pena usar um ORM. Ele diz que vale mais a pena usar uma classe como DAO, com métodos diretos ( por exemplo, um método que conecta, um método que consulta, um método que executa um update ).
Eu tentei entender a situação e o ponto de vista dele, mas não vejo motivos para não usar um ORM em uma linguagem orientada a objeto em um projeto web.
Vocês concordam comigo ou eu não estou conseguindo enxergar alguma desvantagem nesse contexto?
É realmente responsabilidade do gerente de projeto tomar essa decisão?
Pergunto por que o termo pode ser amplo o bastante pra ter responsabilidades bem diferentes.
Pelo que entendi você defende que toda aplicação web usando paradigma OO deveria usar ORM, é isso?
Eu já vi bons argumentos para os dois lados, então a resposta sensata (e no muro) ainda é: Depende.
Procure transformar o que esse “vale a pena” do seu gerente em itens específicos.
Coloque os seus pontos a favor do ORM em itens também.
Comparando as duas listas vocês podem ter idéia do que estarão ganhando ou perdendo seguindo cada caminho.
E não se esqueça que há várias soluções intermediárias entre um Hibernate e JDBC puro na mão.
As vezes a melhor solução para o seu caso está no meio do caminho.
Pede pro gerente fazer então, já que ele gosta de se meter no trabalho que não é dele.
De maneira geral, acho que o principal trade-off a se considerar é questão de performance. Usar ORM estimula a execução de “query’s” menos performáticas (e aumenta também em quantidade). Se você tem requisitos de tempo de resposta muito agressivos (fora do normal), ai usar ORM pode te dar mais dor de cabeça, pois vai haver um custo adicional de sempre “ficar de olho” nas consultas que são geradas.
[quote=rodrigo.uchoa]Pede pro gerente fazer então, já que ele gosta de se meter no trabalho que não é dele.
[/quote]
Concordo plenamente.
[quote=rodrigo.uchoa]
De maneira geral, acho que o principal trade-off a se considerar é questão de performance. Usar ORM estimula a execução de “query’s” menos performáticas (e aumenta também em quantidade). Se você tem requisitos de tempo de resposta muito agressivos (fora do normal), ai usar ORM pode te dar mais dor de cabeça, pois vai haver um custo adicional de sempre “ficar de olho” nas consultas que são geradas.[/quote]
Isso é relativo, Hibernate dá abertura para várias situações. Cada coisa tem que ser usada ao nosso favor. Várias opções nos dão controle da situação quando for necessário, como Criteria (resolvendo a questão de não aumentar número de querys, somente uma é gerada dependendo como você queira criar), Stateless Session em casos que é necessário economizar memória, deixando o processo leve próximo a JDBC puro, mas com a facilidade básica do ORM, cortando recursos avançados. SQL Nativo/Named SQL Query para relatórios, onde geralmente o SQL é complexo, as vezes envolvendo tabelas que nem estão no nosso sistema, com resultado pesado necessitando maior controle para performance. Então não usar ORM para projetos Java OOP com banco relacional só tem vantagem quando a equipe não se sente confortável em lidar com os recursos do mesmo.