Pra que usar um sistema de mapeamento objeto-relacional se você trata seus objetos como dados?
Objeto sem comportamento é exatamente igual a uma estrutura de dados. Reza o mito que você deve ter "classes de negócio" que executam regras. Bom... essas classes fazem coisas com suas classes sem comportamento... então... qual a diferença disso para uma função PHP que manipula linhas em tabelas?
Bom, UMA das diferenças, certamente, é que usamos um monte de traquitanas a mais para obter os dados. Outra é que ganhamos alguns métodos convenientes para buscar dados relacionados. Mas fora isso, qual o ganho?
Sinceramente, mais de uma vez vejo gente defendendo com unhas e dentes frameworks de ORM e usando ele para fazer sistemas que são basicamente, um PHP com mais camadas. E batem no peito pra dizer que é um "Sistema Grande".
Veja, não tenho nada contra ORM. É algo absolutamente necessário se você usa um sistema realmente OO... Caso contrário, é só um trambolho a mais para cuidar.
Como vejo gente demais fazendo isso, eu devo estar deixando escapar alguma coisa muito importante. Mas alguém me diga o quê.
Domingo, Setembro 23, 2007
Pra que ORM se não se usa OO?
Assinar:
Postar comentários (Atom)
4 comentários:
olha eu gosto de ORM para fazer o seguinte, suponha que tenho um campo status no bd, do tipo enum, podendo ser, 1,2,3,4,5
aih no orm eu sobreponho a função status, e faço um switch básico emcima dele mesmo para retornar o status correto. ou para fazer quantidade de estoque reserva, tudo em tempo real kk, mas eu só vi essa utilidade, e a programação em si ficar mais limpa
Bom ponto de vista. Mas a pergunta deveria ser: por que não usar OO? Minha aplicação resume-se a um formulário de contato poderia ser uma boa resposta. Se for um pouco maior que isso, favor rever sua escolha. ;)
Ótimo ponto.
Alguem já olhou para Groovy + Grails?
O framework Grails faz com que o trambolho ORM seja transparente para o aplicativo OO.
Postar um comentário