2007-06-05 04:32:35
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 16)

Para ver os artigos anteriores desta série, clique aqui.

Olá amigos, estamos de volta. Semana de muitas emoções pra quem gosta de Tênis: Roland Garros é sempre uma festa. Este seu humilde autor confessa que, em sua tenra juventude, chegou a disputar alguns torneios; Lembro-me claramente de ganhar uma cesta com catchup, mostarda, mini-pepinos, azeitonas e mais alguns outros enlatados da empresa patrocinadora de um dos torneios de que participei. Minha melhor colocação, 3o colocado. Pensando bem, acho que fiz bem em não seguir a carreira.

Mas, deixando Jankovics, Vaidisovas, Sharapovas e Ivanovics de lado por alguns momentos, quero voltar nossa atenção novamente para os modelos do MVC. Muito bem amigos, hoje vamos tentar definir o que todos os nossos modelos devem minimamente fazer. Nosso objetivo hoje é listar os métodos da nossa classe Model, a classe base para todos os modelos que criarmos. Não tenho a pretensão de fazer um estudo teórico detalhado; dentro de nossa filosofia PHP de Rua® o que estamos buscando é somente o básico, o essencial.

Então, caros amigos, quais seriam estas funções essenciais, compartilhadas por todos os modelos que vamos criar? Lembrando nossas conversas anteriores, o modelo é um ajudante, uma classe que só existe para ler e gravar informações em nosso banco de dados, e sua estrutura de dados será sempre mapeada à estrutura de uma tabela que existe no BD.

Por exemplo, se criarmos um modelo Tenista, que possua as variáveis $id$nome$ranking, é certo que teremos uma tabela que guardará esta informação, que pra facilitar (nomes têm poder, lembrem-se disso) chamaremos de Tenistas. Essa tabela terá, minimamente, os campos id, nome e ranking. Sacou?

Estamos, de fato, mapeando uma classe à uma tabela, e instâncias da classe a registros da tabela. Essa técnica é chamada de ORM, Object-Relational Mapping. A coisa é mais interessante ainda: como estamos falando de OOP, em algum de nossos métodos vamos bolar um jeito de fazer esse mapeamento da forma mais simples e genérica possível, pra que não tenhamos que criar queries sql específicas para cada novo modelo que criamos.

Vejam a beleza dessa solução, caros leitores! Quando terminarmos a classe Model, qualquer novo objeto de uma classe que a estenda poderá ser salvo ou lido direto do banco sem precisar que nós façamos uma query específica!

Sendo assim, creio que já ficou bastante claro que precisamos das funções save() e load() em nosso modelo-base. A gente não precisa gastar muitos neurônios pra perceber que também precisamos da função delete() além da função __construct() que todos as classes já nos oferecem para criar novos objetos.

Nesse ponto começa uma saudável polêmica: onde devem ficar as funções para buscar objetos? Se eu quiser pegar todas as tenistas que estão no banco, pra quem eu devo pedir? Em alguns frameworks MVC, como o CakePHP, estas funções ficam na classe Model mesmo. Então vocë encontra funções como findAll(), findById(), findByName() e coisas assim, dentro da classe Model.

Pra ser muito sincero, eu acho meio esquisito pedir pra uma tenista buscar as outras tenistas. É assim que fica no CakePHP:

$tenista = new Tenista();

$todasastenistas = $tenista->findAll();

Cara, eu acho isso muito esquisito. A semantica da coisa, sabe? Acho que é um pouco de preciosismo, eu sei. Adoro o Cake, estou realmente impressionado com sua facilidade de uso, mas acho o design da classe model um pouco confusa.

Outros frameworks e ORMs fazem diferente. Criam uma classe só pra fazer isso. Um gnomo, lembram-se? Então, o cara faz o seguinte:

$gnomo = new DbManager();

$todasastenistas = $gnomo->findAll('tenista');

 Nesse caso, a classe DbManager tem todos os tais métodos pra retornar arrays buscados no banco. Hm. Acho um pouco melhor, mas ainda acho estranho não termos uma classe mais esperta, que possamos estender para criar comportamentos diferentes caso a gente precise. A resposta está próxima, caros amigos. Mas não posso perder a chance de continuar no próximo capítulo, não é mesmo?

Até a próxima.

16 Comentários:

[Walter]  O primeiro padrão é o Active Record, enquanto o segundo é o DataMapper(?). Confesso que a princípio a semântica do primeiro parece meio esquisita mesmo. Ainda não sei por qual optar, embora esteja namorando o SQL Alchemy (Python)  [REPLY]

[Emiliano ESB]  Maravilha!!! Também partilho da mesma opinião   [REPLY]

[Renan Reis]  Os artigos estão ótimos, finalmente alguém resolveu escrever sobre código de qualidade com PHP. Parabéns pela série!  [REPLY]

[Renato Elias]  Engraçado você postar sobre tenista, roland garros, bem quando eu acabei de terminar um projeto de scout, veja se vc gosta: http://www.datatennis.com foi feito em phpontrax, bem parecido com o cake que você cita, abraços  [REPLY]

[Thiago]  A série realmente está muito boa, pena é o grande intervalo entre os posts :( Grandes abraços e sucesso ... você merece !!  [REPLY]

[Filipe Boldo]  Ótima epopéia cavaleiresca, com direito a gnome e tudo (rs). Está sendo muito agradável e proveitoso ler esses artigos, parabéns mesmo! Abraço, até mais!  [REPLY]

[Fabiano M.]  Muito bom, continuo acompanhando. Eu estou iniciando no mundo framework com cakePHP, mais jah olhei outros. Falando sobre OOP, na parte sobre interface, kara eu acho muito confuso ainda interfaces, tanta volta para um resultado. Estou ainda meio perdido em compreender interface. Mas agradeço por poder aprender mais por aqui no seu blog. Valeu!!!  [REPLY]

[Pagelkopf]  Parabens pela série, lendo ela eu descobri porque meu ultimo projeto em PHP não funcionou, eu sentei e comecei a digitar sem o minimo de planejamento. Ta sendo realmente muito proveitosos seus artigo. No final vai dar até pra fazer um livro.  [REPLY]

[Fabiano M.]  Tenho acompanhado o blog DigitalMinds, muito bem explicado os conceitos. Moro no Rio, como até hoje não encontrei nenhum curso PHP bom, tenho aprendido na web muito do que sei hoje. Iniciando em OOP, DigitalMinds sem dúvidas é um dos melhores conteúdos online. Como estamos no mundo dos 64Bits, bem q a 32Bits poderia ser 32²Bits. :) Valeu, abraço!  [REPLY]

[LuRsT]  Estou a adorar sua serie cara, continue assim, graças a ela eu começei a estudar OOP em php. Abraço cá de Portugal ;)  [REPLY]

[danilo]  Valeu Walter! Abraço grande!  [REPLY]

[Luiz]  Opa, to ansioso para continuar a aprender! Cadê o resto!? hehe, ok, ok, sei que o tempo é curto! Obrigado por gastar um pouco compartilhando conhecimento! Abraços.  [REPLY]

[danilo]  Valeu Luis! O próximo artigo já tá quase pronto! Aguarde só mais um pouco! hehehe Grande abraço.  [REPLY]

[danilo]  Um grande abraço pra os gajos daí Lurst!  [REPLY]

[danilo]  Fabiano, interface é um contrato. Se uma classe utiliza uma determinada interface, ela é obrigada a ter aquelas funcões. E isso é muito, muito importante, pq se vc sabe que uma classe implementa uma determinada interface, você já sabe do que ela é capaz sem precisar saber como ela faz. Faz sentido? Grande abraço!

[Fabiano]  Oq houve com os comentários???   [REPLY]