[Cascavel-pm] Arquivo configuracao a parte

[Nilson Santos Figueiredo Junior]

On 8/14/06, Luis Motta Campos <monsieur_champs em yahoo.com.br> wrote:
>   Claro, e esquece que existe performance... ;-) tem poucas coisas com
> performance tão porca como mapeamentos objeto-relacionais... :-/
>
>   Eu aconselho fortemente a pensar direito no que você está fazendo e
> escrever seus SQLs separados do seu código. É mais rápido e mais flexível.

Certo. Eu poderia escrever um tratado refutando essas afirmativas mas
vou me conter, devido ao horário. De qualquer forma, vale à pena dizer
algumas coisas.

A primeira e mais relevante motivação para se usar um mapeamento
objeto-relacional se resume ao seguinte: meu tempo vale mais que o
tempo do computador.

Um mapeador objeto-relacional como o DBIx::Class contribui para a
qualidade técnica do seus sistema em vários níveis.

O benefício mais óbivio é que sua aplicação se torna automaticamente
portável para qualquer um dos bancos de dados suportados (todos os
relevantes atualmente) sem se preocupar com reescritas de queries
porque o MSSQL não usa pontos-e-vírgulas no final de queries ou coisas
assim. Infelizmente, SQL não é universal e várias coisas cruciais
(como pegar o ID de uma entrada que acabou de ser inserida) variam
drásticamente de RDBMS para RDBMS e uma abstração é extremamente
necessária.

O outro benefício é que o DBIx::Class faz com que suas entidades de
dados sejam vistam como objetos em sua aplicação. Por isso,
modificações na estrutura do seu banco de dados ficam completamente
isoladas do resto da sua aplicação. Em sistemas em evolução isso é
extremanente importante. Um dos casos mais comuns é você ter um campo
em uma tabela e aquele campo ter que se tornar uma tabela separada por
alguma razão. Quando se utiliza algo como o DBIx::Class essa alteração
fica 100% transparente no seu programa.

Por fim, vale lembrar que o DBIx::Class gera queries altamente
eficientes, sempre utilizando os JOINs corretos e é absurdamente
simples de fazer com que ele busque todos os relacionamentos em uma
query só, montando todos os JOINs para você automaticamente. Esse é o
ponto final aonde a utilização do DBIx::Class faz com que a qualidade
técnica de sua aplicação melhore: no modelo relacional. Quando você
tem queries "difíceis" de serem feitas utilizando o DBIC, isso é um
forte indício de que você deveria ter criado uma View (ou stored
procedures) em seu RDBMS para aquele conjunto de dados.

A utilização de um mapeador objeto-relacional faz com que seu sistema
fique muito mais flexível como aplicação em Perl, que é o que importa
pra mim, pelo menos. E se você realmente *precisar* escrever código em
SQL em sua aplicação ele permite que você o faça, sem quebrar a sua
arquitetura, mas utilizando a query escrita por você para gerar os
resultados para construção dos objetos.

Como eu disse, eu poderia escrever muito mais. Dar muito mais exemplos
de como as coisas ficam mais flexíveis e eficientes. Mas, hoje em dia,
o DBIx::Class é razoavelmente bem documentado e a maioria poderia
descobrir essas coisas sozinho. Mas caso ainda assim alguém possua
dúvidas sobre o DBIx::Class (ou o Catalyst) ficarei feliz em tentar
ajudar no que eu puder. Só não me peçam ajuda em SQL pois eu já estou
quase esquecendo essa linguagem medonha. ;-)

-Nilson Santos F. Jr.