MVC simples e prático, Parte I

Fala pessoal!

Sim, assunto batido! Model View Controller! Mas é muito comum encontrarmos pela internet tutoriais um pouco estranhos, visões às vezes que parecem particulares, diagramas errados e alguns ainda com dúvidas.

O conceito do MVC é extremamente simples mas a sua visualização não é lá tão trivial assim. O artigo tem 2 objetivos principais: Relembrar a teoria e mostrar uma visualização simplificada do conceito.

Então vamos lá!

Entendendo o papel do M – Model

Pessoal, a idéia é simples: Quando pensamos em regras de negócio, estamos pensando no Modelo da aplicação. Basicamente é isto. No Model podemos ter validações, acesso a banco, acesso à arquivos, cálculos, etc.

O usuário, por exemplo, coloca um produto em um carrinho de compras e é no Model que faremos o cálculo final do pedido(descontos, juros), que validaremos a conta do usuário, que calcularemos o frete, que validaremos o endereço e por aí vai.

Mas como o usuário seleciona um produto em um carrinho de compras por exemplo? Como insere um Endereço para a entrega? Na View!

Entendendo o papel do V – View

A View só existe por um único motivo: Mostrar dados! Na prática isso nunca muitas vezes não acontece, mas deveria! Você que já desenvolveu em Delphi/VB com toda certeza já viu regras em um botão. Você que já desenvolveu em Java também já viu centenas de regras nas páginas JSP ou espalhadas em Servlets que criam as páginas. Isso é feio! O dia que precisarmos mudar de JSP para JSF ou GWT simplesmente não mudaremos!

Mas e agora? Entendido o conceito básico do Model, como a View passa os valores digitados/selecionados para o Model? Passa direto? Não!

Entendendo o papel do C – Controller

Aqui temos um maestro! Temos regras de negócio no Controller? Não! Temos visualização no Controller? Não! O Controller simplesmente delega para o Model as solicitações da View. O Controller é burro no sentido de regras de negócio da aplicação. Ele é responsável por saber quem está pedindo algo e a quem enviará este algo!

O Controller conhece a View e conhece o Model mas o Model não conhece a View, porém a View observa o Model e este avisa quando seus dados foram atualizados, para a View mostrá-los.

Ok! Depois dessa frase bagunçada, nada como um pequeno esquema para entendermos melhor:

Diagrama MVC

Entendendo o MVC

Veja como é simples com o diagrama acima:

O Controller conhece a View e conhece o Model. Isto porque ele recebe as requisições do usuário da View e envia para o Model fazer algo com estas requisições. Exemplo: O usuário quer saber o endereço de uma residência a partir de um cep digitado.

O Model simplesmente recebe a requisição, faz toda a mágica (persiste dados, valida informações, etc) e fica com os dados prontos (atualizados) para serem visualizados novamente pela View.

A View fica observando o Model e quando este é atualizado, a View mostra os dados atualizados para o usuário.

E o Model acaba não conhecendo ninguém!

Legal! E por que eu trabalharia desta forma?

Porque, além de elegante, é profissional! Mas se você não se convenceu com estes argumentos, podemos ter outro: é Seguro! Temos aqui uma separação bem clara entre a Visualização e as Regras de Negócio. Caso você queira modificar uma regra, como um cálculo de juros, você precisaria apenas modificar o seu Model (e espero que em um só local! =) )  e não precisaria se preocupar com a visualização.

O mesmo vale para a View. Caso você queira modificar uma tela inteira, não precisaria se preocupar com as regras e sim somente com a tela.

Um outro motivo muito forte é que você pode querer disponibilizar os seus métodos em um WebService por exemplo e com uma separação clara do seu modelo, isso seria facilitado, e muito! Imagine que você tenha uma aplicação Web e outra Desktop (JSF e Swing por exemplo) mas que façam a mesma coisa. Seria muito ruim ter funcionalidades iguais nos dois ambientes pois teríamos que manter as duas iguais. Uma forma seria disponibilizar as funcionalidades em um ponto único e acessá-las nas duas aplicações. Com uma separação clara do modelo poderíamos disponibilizar estas funcionalidades por um WebService, Rest, EJB, etc.

Finalizando

O MVC é um padrão de arquitetura que existe, a grosso modo, para facilitar a manutenção da nossa aplicação, facilitar a adição de funcionalidades e facilitar a testabilidade da aplicação.

Se você ainda escreve regras de negócio nas suas páginas/forms, tente desenvolver com este padrão e veja a diferença na manutenção e na adição de funcionalidades.

No próximo post veremos um exemplo simples de implementação de uma funcionalidade utilizando o padrão MVC e veremos como é simples melhorarmos a nossa aplicação deixando-a profissional.

É isso pessoal! Abraços!

About these ads

12 comentários

  1. Muito bom seu artigo, estero que continue assim, não vejo a hora da parte 2, pois estou começando a programar e sempre embanano principalmente no uso do controller, acho que com seu exemplo vou sanar minhas duvidas.

    1. Olá Rogério!
      Muito obrigado pelo comentário. Já escrevi as partes 2 e 3 mas infelizmente não tive tempo de revisar e publicar. Espero publicar esta semana
      e poder ajudar nas suas dúvidas.

      Abraços!

  2. Alexandre muito bom o seu post. Eu vejo muita gente fazendo muita confusão com o MVC e principalmente misturando as responsabilidades. Acho que só tem um detalhe aí no desenho: a view teria uma seta (indicando uma referência) para o controller e para reforçar isso, o faço através de uma citação sua “ele (o controller) recebe as requisições do usuário da View”. Então a view acessa o controller. Caso discorde, então deveria ter um intermediário/gerenciador entre a view e o controler mais explícito. Pois a view solicita uma ação a alguém. Este alguém (intermediário) decide qual o controler+action vai chamar qual model.

  3. Oi Rogério!
    Estou procurando melhorar a qualidade de software que desenvolvo e estou iniciando com mvc e dao. Gostei do seu artigo e aguardo as partes 2 e 3 com exemplos práticos. Tenho certeza que vão ajudar bastante. Por enquanto, muito obrigado!

    abraço,

    Paulo

  4. Você copiou o post do site da empresa de treinamento o k19, e fez isso somente um dia depois deles. Nada contra, acho até legal disseminar conhecimento assim, mas você poderia, pelo menos, colocar a url de conde você copiou isso.

    1. Olá Jones, tudo bem?

      Na verdade eu que escrevi o post da K19. Eu era colaborador da empresa e escrevi alguns posts por lá.

      Eu realmente não aprovaria copiar artigos.

      Abraços!

  5. Alexandre, parabéns pelo artigo. Sempre procuro informações sobre MVC porque simplesmente não consigo (ainda) separar as coisas. Depois de ler, passei a acreditar que meu problema era entender como o conceito era abordado nas outras fontes.

    Ficou mais fácil agora.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s