Os princípios do MVC para desenvolvedores PHP

Os conceitos por trás do MVC, remontam à década de 60 e influenciaram linguagens de programação orientadas a objetos, como o Smalltalk-80 e incontáveis projetos, como o Apple Macintosh.
Sigla para Model-View-Controller ou Modelo-Visão-Controlador, o MVC pode ser definido como uma arquitetura de software ou padrão de projetos (design patterns).

Se isto fizer alguém se sentir mais seguro e confiante, não estamos falando de conceitos que “surgiram ontem” aqui.
Quando me pediram para escrever sobre o MVC (Model-View-Controller), tal como Marc Plotz, tive a percepção de que há muito pouco escrito sobre o assunto, que se possa chamar de relevante (eu sei, isto é apenas uma opinião) — alguns termos carecem de uma definição mais aprofundada.
Mas, quem deseja se aprofundar mais sobre um determinado assunto, deve procurá-lo em livros, enquanto meios mais adequados e confortáveis para se explorar conceitos.
Neste artigo, vou procurar expor o que sei sobre MVC, da maneira mais simples possível e sob a ótica de um programador PHP – onde reside boa parte da minha experiência enquanto desenvolvedor.

Vantagens do MVC

Para ser objetivo:

• robusto;
• escalável;
• enxuto e muito bem escrito.

Quando eu era adolescente, meu pai, doutor em matemática, me deu alguns conselhos sobre como programar melhor. Um deles dizia “seu código não deve ultrapassar o tamanho de uma tela”.
Pode parecer bobagem, mas seguindo este princípio, nos anos 90, antes de ter qualquer formação acadêmica, eu já aplicava alguns dos conceitos da boa programação de que vamos falar aqui.
Ao seguir este princípio, sou obrigado a pensar o meu código para ser enxuto e livre de redundâncias.

O que é o MVC

A arquitetura de software MODEL – VIEW – CONTROLLER, usada na engenharia de softwares tem como princípio fundamental a idéia de que a lógica de uma aplicação deve estar separada de sua apresentação — ou seja, o MVC é uma maneira melhor de separar a lógica de construção da sua aplicação do modo como ela é vista.
Sua fundamentação é separar a aplicação em 3 partes principais, conhecidas como o Modelo, a Visão e o Controlador.
Observe o diagrama:

• As linhas contínuas representam as associações diretas
• As linhas tracejadas representam as associações inferidas

Estas últimas, são associações visíveis pelo ponto de vista do usuário, mas que não representam necessariamente a realidade do projeto de software.

Uma das formas de pensar o MVC é considerar as seguintes situações:

• Um usuário interage com o view, clicando em um link ou enviando dados em um formulário.
• O Controller manipula os dados fornecidos pelo usuário e os transfere ao Model.
• O Model recebe a informação e atualiza seu estado — o que significa realizar um cálculo envolvendo os dados fornecidos, adicioná-los a um banco de dados, pra citar alguns exemplos.
• O View verifica o estado do Model e responde — listando os dados, fornecendo o resultado de um cálculo etc.
• O View aguarda uma nova interação vinda do usuário.

Em termos práticos, o MVC representa uma boa filosofia de projetos.
A ideia de separar a ĺógica do display não é nova — mas o MVC consegue apresentá-la de uma forma mais amigável.
A apresentação e o layout são mais simples — e, como consequência, seu aplicativo pode ter uma manutenção mais fácil.
O View fica entre os arquivos de view, a lógica dentro do modelo (template) e o Controller manipula tudo.

A lógica de negócios

O termo, em inglês, é Business Logic.
O conceito é simples: lógica de negócios é o processo de calcular os processos lógicos de uma aplicação.
Exemplo: no caso de um calendário, a lógica de negócios consistiria em calcular a data atual, em que dia da semana estamos, quantos dias já se passaram desde o início do ano ou do mês etc.
Não se deixe confundir por termos bonitinhos — em uma aplicação a lógica de negócios se refere ao processamento das informações — simplesmente.

São rotinas que realizam entradas de dados, consultas aos dados, geração de relatórios e mais especificamente todo o processamento que se realiza por trás da aplicação visível para o utilizador (Backoffice). (Wikipedia)

Modelos

O termo, em inglês (para facilitar sua busca, caso deseje pesquisar mais sobre o assunto) é templates.
É comum frameworks MVC usarem algum tipo de sistema de modelos, para enfatizar o princípio DRY (veja abaixo), tornando mais fácil reusar código já pronto.
Há frameworks que rodam sobre o Smarty ou seus próprios mecanismos de modelos – ou nenhum.
Especialistas avisam que alguns mecanismos de modelos (template engines) possuem sintaxe um tanto complicada — o trabalho de aprendizagem pode não valer a pena. Se informe antes de começar a aprender uma nova linguagem, que pode servir apenas para renderizar páginas.

DRY

A palavra dry, em inglês, que dizer “seco” ou “enxuto” — isto pode ajudar a memorizar.
No contexto de que estamos tratando, tem outro significado: Don’t Repeat Yourself — ou seja, não se repita ou não seja redundante.
A ideia é que você escreva código uma vez apenas e o reuse sempre que for necessário.

Na engenharia de software, o princípio DRY (não seja redundante) é usado para evitar repetição de informações e de trabalho.
“Cada peça de conhecimento deve ter uma única e não ambígua representação autoritativa dentro do sistema”. (Dave Thomas, 2003).
O princípio foi formulado pelos autores do livro “The pragmatic programmer“, Andy Hunt e Dave Thomas.
Sua aplicação inclui esquemas de bancos de dados, planos de testes, documentação etc.

A correta implementação deste princípio, implica que alterar um elemento dentro do sistema, não afeta outros elementos não-relacionados.

Programação por convenção

Este é um paradigma de projeto de software, que busca reduzir o número de decisões que os desenvolvedores precisam tomar — tornando o processo mais simples mas, nem por isso, menos flexível.
Assim, o programador só precisa especificar aspectos não convencionais da aplicação.
Por exemplo: havendo uma classe Vendas, dentro do modelo, a tabela correspondente, dentro do banco de dados, vai se chamar também “vendas”, por padrão.
Código “extra” relacionado a estes nomes, só vai precisar ser escrito, se alguém usar um nome diferente pra tabela.
Se pensar bem, é muito simples.
Leve em consideração um formulário:

• ele tem elementos que sempre são requeridos;
• estes elementos têm estados que, comumente, são os mesmos;
• Um formulário, em meio ao código HTML, tem uma tag <form> que especifica uma ação a ser tomada, um método, um nome, uma id etc.
  Se você não precisa alterar nada, é mais fácil obter logo o nome do form, seu id, ação etc. direto da url.

Aplicar esta ideia a todos os elementos torna a construção deste tipo de aplicação muito fácil, rápida e simplificada.

Conclusão

O assunto não se esgota neste artigo — e pretendo retomá-lo em outros posts.
Tal como foi dito, até aqui, o MVC é uma maneira de começar a produzir de maneira limpa, escalável e robusta — e escrever código rápido, no menor espaço de tempo possível, com o mínimo de esforço.
Alguns frameworks MVC possuem apenas um ou dois destes recursos. O conselho é experimentar até encontrar um que te sirva.
Como sempre, sinta-se à vontade para comentar e compartilhar sua experiência comigo e com os outros leitores.

Leia mais

http://c2.com/cgi/wiki?BusinessLogicDefinition
http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software