Este artigo mostra como fazer com que uma aplicação PHP orientada a objetos utilize a arquitetura MVC através de um exemplo simples, porém que utilize os recursos básicos de persistência e consulta a base de dados MySQL.
Para que serve
A orientação a objetos é a melhor forma para se construir uma aplicação, porém muito se fala na arquitetura MVC, que divide em camadas as classes existentes e, entre outras coisas, facilita o desenvolvimento em equipe.
Em que situação o tema é útil
A arquitetura MVC organiza o código e facilita o desenvolvimento em equipes multidisciplinares. Com o exemplo aqui apresentado será possível entender como tornar uma aplicação orientada a objetos em uma aplicação MVC.
Resumo do DevMan
As técnicas empregadas no desenvolvimento de software são essenciais para o sucesso do mesmo. Boas práticas como TDD, padrões de projetos, orientação a objetos e MVC estão em constante destaque na internet e publicações especializadas. Com isso, uma técnica que vem tendo bastante destaque é o MVC, porém poucas pessoas sabem como migrar a arquitetura de suas aplicações OO para a arquitetura MVC. Neste artigo primeiramente iremos tratar de toda parte conceitual que envolve o MVC, e em seguida construiremos um pequeno projeto OO onde utilizaremos as funções básicas de Insert, Update, Delete e Select para na sequência modificarmos passo a passo a arquitetura do projeto para MVC.
Autores: Lucas Simões Maistro e Raphael Zanon Rodrigues
Visando o crescente aumento da necessidade de desenvolvimento de sistemas com prazo quase sempre curtos, seja por falha no levantamento de informações, definição de requisitos, projeto ou qualquer outro fator, nesse artigo, visamos abordar um assunto bastante pertinente a todos nós desenvolvedores com foco em um projeto de sistema para internet. Iremos abordar o padrão de arquitetura da aplicação, o padrão MVC.
Resumidamente, o padrão MVC, que significa Model-View-Controller, tem como objetivo a divisão de tarefas específicas em um sistema, aumentando a produtividade de desenvolvimento do projeto, pois facilita a identificação e alteração em qualquer parte dele, seja em um módulo ou no visual.
Padrões de Projeto (Design Patterns)
Padrões de Projetos podem, basicamente, serem vistos como uma solução já testada para problemas que alguém já passou e o solucionou aplicando um modelo básico que foi documentado, permitindo que nós utilizemos esse modelo integralmente ou adaptado de acordo com as necessidades da nossa solução, o que resulta na redução do tempo gasto com o desenvolvimento e possíveis melhorias na qualidade de uma aplicação.
Um Padrão de Projeto tem como características a Generalidade, Equilíbrio, Abstração e Combinatoriedade, ou seja, todo padrão deve permitir a construção de outros projetos a partir dele, permitir o relacionamento de cada uma das restrições encontradas com cada passo do projeto, possibilitar a aplicação de soluções adquiridas por meio de abstrações feitas sobre conhecimentos adquiridos em outras experiências e o relacionamento de forma hierárquica com outros padrões.
A utilização de Padrões concede, de forma geral, vantagens como redução no tempo de codificação, reaproveitamento de código, diminuição no tempo de manutenção, aumento na interação entre a equipe de desenvolvimento, padronização do código e a possibilidade de generalização do sistema. O grande desafio das equipes de desenvolvimento de aplicações é produzir aplicativos cada vez mais seguros, eficientes, de fácil manutenção, reutilizáveis e em prazos cada vez menores.
Quando e como utilizar um padrão para desenvolvimento de uma solução? Atualmente, o principal desafio para as equipes responsáveis pelo desenvolvimento de soluções é criar aplicativos seguros, eficientes, com manutenção simples, códigos reutilizáveis e ainda, em prazos cada vez menores. Dessa forma, a primeira coisa que devemos ter em mente é o bom senso, ou seja, realizar o levantamento dos requisitos e definir o escopo do projeto. Depois dessa primeira fase devemos identificar possíveis deficiências e se o projeto pode ser otimizado. Feito isso, se for o caso, utilizaremos o padrão de projeto que se ajusta melhor à solução para sanar as deficiências levantadas.
Nos últimos tempos, o paradigma do modelo orientado a objetos vem tendo avanço significante, o que torna impensável o fato de se desenvolver novos projetos que não sejam orientados a objetos desde o início. Porém, para atingirmos com sucesso o desenvolvimento desses novos projetos, torna-se cada vez mais necessário, levarmos em consideração a arquitetura que vamos utilizar para tal. Com base nas tendências e observação dos padrões utilizados no mercado, chegamos à conclusão de que a organização desses novos projetos será em camadas.
O desenvolvimento de novos projetos com o conceito de organização em camadas é, basicamente, utilizar cada tecnologia para a finalidade em que ela foi desenvolvida. Organizando nossos projetos em camadas atingimos a independência das mesmas e a partir de então é que conseguiremos atingir os objetivos de desenvolver aplicações seguras, eficientes, com manutenção simples e códigos reutilizáveis.
Desenvolvimento em Camadas
A nomenclatura “camadas” pode parecer um tanto quanto nova, porém, desde o surgimento da arquitetura cliente/servidor, o desenvolvimento de aplicações em camadas passou a ser adotado, mas com a popularização da internet, os cuidados com a arquitetura das aplicações têm ganhado cada vez mais visibilidade. Mesmo assim, entendemos que o desenvolvimento de aplicações multicamadas pode parecer em um primeiro instante, mais complexo do que realmente é. Pensando nessa dificuldade, vamos explicar como foi a evolução desse conceito.
Em um primeiro momento, as aplicações eram criadas para serem usadas em uma única máquina. Dessa forma, tais aplicações continham apenas um único módulo com todas as funcionalidades como: validações, lógica de negócio e acesso a dados, incluídas nele o que resultava em uma enorme quantidade de linhas e bastante sofrimento quando tinha necessidade de manutenção. A Figura 1 mostra como era esse tipo de aplicação.
Figura 1. Modelo em uma única camada
Passado algum tempo, onde os computadores começaram a se popularizar, surge a necessidade de se ter vários usuários acessando de forma simultânea a base de dados. Nesse ponto, a base de dados foi colocada em uma máquina separada das máquinas que utilizavam as aplicações. Essa arquitetura trouxe vantagens em relação a sua antecessora, aumentando a velocidade na rede e o processamento deixou de ser totalmente centralizado. Temos na primeira camada o cliente, onde se encontra a apresentação, as regras de negócio e o acesso aos dados, que se conectam a uma segunda camada (servidor), onde está o banco de dados (Figura 2).
Figura 2. Modelo em duas camadas
As aplicações três camadas, também conhecidas como multicamadas ou multitier, são uma evolução do modelo cliente / servidor, onde surge uma (ou mais) camada intermediária entre a parte cliente e o servidor de dados. O ponto fundamental desse modelo é a divisão distinta entre as camadas onde não há a intromissão de uma na outra. A divisão é feita entre as camadas de apresentação, de negócio e de dados, como mostra a Figura 3.
Figura 3. Modelo em três camadas
Arquitetura MVC: Controlador, Modelo e Visão
O padrão MVC tem como princípio que o desenvolvedor tem três peças que trabalham em conjunto para formar uma aplicação mais complexa, sendo criada originalmente para resolver o problema de interação do usuário com a aplicação, deixando que essa interação propriamente dita ficasse isolada das regras de negócio. Para exemplificar vamos utilizar a ideia de um carro. O carro possui duas Visões (Views), sendo elas o exterior e o interior. Ambas pegam as ações de um Controlador (Controller), o motorista. Os freios, aceleração, partida e outras funções representem o Modelo (Model). Como funciona? As Visões capturam os eventos externos, o Controlador (motorista) interpreta os eventos "crus" dados pela visão passando para o Modelo quando necessário, que por sua vez devolve os resultados às Visões.
...
