[SP-pm] ORMs

Eden Cardim edencardim at gmail.com
Mon Sep 29 03:04:55 PDT 2008


2008/9/28 André Walker <andre em andrewalker.net>:
> Acabei de voltar da PGCon, e conversei com David Fetter. Perguntei o que
> ele achava de ORMs, como a DBIx::Class. Ele disse que as coisas são tão
> boas no Unix porque cada ferramenta é muito boa em uma coisa, mas ORMs
> não são assim. No final, acabam dando mais trabalho. Parece que havia um
> consenso lá que ORMs em geral (o Hibernate foi muito citado) só deixavam
> o programa mais pesado e limitavam o potencial do banco.
> DBA's não gostam muito delas então. E os programadores Perl? Já vi um
> artigo do Champs falando sobre CGI::Application, Class::DBI e Template
> Toolkit. O que você acha hoje sobre Class::DBI e DBIx::Class? E os
> outros?

Não sei quanto aos outros projetos, mas a minha experiência é de que
os DBA's gostam de falar mal do DBIx::Class sem fazer idéia de como
funciona ou como projetar uma aplicação para usá-lo. No FISL o David
Fetter veio conversar comigo sobre a possibilidade de se iniciar um
projeto para criar uma camada de acesso a dados em Perl. Quando ele me
descreveu os requisitos do que ele consideraria uma camada de acesso
ideal (basicamente, uma biblioteca de consultas mantida por um DBA,
que retornaria os dados serializados em JSON ou algo do gênero), já
tinha tudo no DBIx::Class, eu escrevi um componente que fazia isso na
frente dele e tudo funcionou perfeitamente. Vou me ater ao DBIx::Class
porque é o ORM com o qual eu tenho conhecimento mais profundo, vamos
aos mitos:

1) O DBIx::Class é uma tentativa de magicamente generalizar o acesso a
dados e eu não preciso escrever código adicional para integrá-lo com
minha aplicação.

Errado, o DBIx::Class é meramente uma API de acesso a dados com uma
implementação padrão componentizada para que você possa escolher
exatamente quais features dele você quer usar ou não. Uma das decisões
de projeto da API foi de fazer a abstração para classes/objetos, isso
o coloca na categoria de ORM, mas não é um ORM tradicional.

2) O DBIx::Class vai me fazer misturar SQL com meu código

Não necessariamente, o DBIx::Class permite que você use a estrutura de
classes e pacotes como bem entender, isso significa que você pode
delegar as consultas para uma classe/pacote específico.

3) O DBIx::Class vai gerar SQL por mim ...

Por padrão sim, mas você pode optar por não usar a API/implementação
de geração de SQL dele (SQL::Abstract) e implementar algo você mesmo.
Você também pode optar por usar a sua implementação customizada, em
paralelo com a implementação padrão, que é o que eu faço na maior
parte dos casos.

4) ... e por isso minha aplicação vai ficar mais lenta

Não necessariamente, a minha experiência é de que o ganho de
desempenho em consultas mais simples é tão mínimo que não justifica o
tempo que se perde, tanto em tempo bruto de escrita de código quanto
em tempo perdido com protocolos de processo de desenvolvimento,
mandando um DBA escrever cada uma delas a mão. O DBIx::Class se vira
muito bem com as consultas mais complexas, e as consultas mais lentas
podem ser customizadas/otimizadas depois com bastante facilidade. Isso
permite que o seu DBA possa focar em aspectos mais críticos do banco
de dados.

Um caso de sucesso que gosto batante de citar foi um componente que
escrevi sob medida pro takkle.com para implementar uma otimização
geral nas consultas que teria custado alguns meses e milhares de
dólares para implementar manualmente em todos os pontos da aplicação
que faziam acesso ao banco. O tempo total de
projeto/implementação/teste foi de cerca de 90 dias, isso adiou a
aquisição de novos servidores em cerca de 4 meses e o DBA deles está
bastante contente com a solução.

-- 
edenc.vox.com


More information about the SaoPaulo-pm mailing list