Muito se fala sobre MVC. O Rails, o Laravel e muitos outros frameworks do mercado utilizam esse padrão. Mas afinal, o que isso quer dizer?
É natural que talvez você tenha se deparado durante sua jornada de aprendizado com alguns exemplos de aplicações onde se constroi toda a solução em um único arquivo: se obtém os dados, trata o fluxo de envio e recebimento de dados e, às vezes, até controla a renderização do resultado. Mas esse com certeza não é um padrão escalável, ou fácil de dar manutenção a médio e longo prazo.
Por ser um problema recorrente, há padrões de projetos já consolidados, onde temos destaque ao MVC pela sua simplicidade de implementação, flexibilidade e também a facilidade de reutilização de código. Falaremos mais sobre suas características.
Imagine que você está criando um sistema para controle de gastos. Ao invés de fazer a consulta e inserção de dados no mesmo código em que você monta seu layout e valida seu formulário de cadastro, você possui classes e estruturas específicas para cada uma dessas responsabilidades.
Há uma classe responsável por manipular os registros de controle de gastos. Ela irá intermediar a conexão entre sua aplicação e o banco de dados, armazenando e obtendo os registros de sua respectiva tabela. No padrão MVC esse tipo de classe é chamada de Model.
A exibição de dados, em formato JSON ou numa tabela HTML, fica sob responsabilidade de da View. É nela que vai estar estruturado seu formulário de cadastro. Mas para que o Model e a View possam se comunicar é necessário que exista uma maneira de transmitir os dados obtidos do banco.
Para isso existe uma classe conhecida como Controller, que é responsável pelo gerenciamento do fluxo das requisições que sua aplicação recebe e envia. Ela atua verificando se o usuário está devidamente autenticado, fazendo chamadas ao Model para obter ou salvar os dados e disponibilizando tais registros para que possam ser exibidos corretamente na View. Se precisarmos criar algum comportamento específico quando nosso formulário estiver inválido, é no Controller que essa condicionalidade será implementada.
Mas por que isso parece tão transparente no Rails? Uma das filosofias fundamentais do Ruby on Rails é a convenção sobre configuração, de maneira que não precisamos ficar reescrevendo comportamentos ditos padrões.
Então, por mais que você não veja nenhum código que faz menção sobre acessar o banco, ou um trecho de código de código que obtém a view e sua respectiva renderização passando as variáveis que atribuímos no controller, esse código ainda está lá através da herança de classes nativas do framework. Se você criar uma aplicação Ruby com Sinatra, ou em Node.js utilizando Express, você entenderá como esse código precisará ser escrito.
Voltando ao Rails, uma coisa que gosto é que em projetos MVC tudo pode ser facilmente estendido. Se em algum momento do projeto o Controller ou o Model estiver complexo demais, com muitas linhas de código e assim comprometendo a manutenção, você pode facilmente criar classes especialistas. Podemos:
- encapsular o repositório de consultas ao banco, utilizadas em múltiplos lugares, evitando assim replicação de código;
- criar classes que ficarão responsáveis por um extenso e complexo processo ao salvar um registro via Model;
- componentizar o disparo de notificações ao usuário;
- padronizar o envio de dados a sistemas externos;
- dentre outras coisas…
Então, depois de entender mais sobre MVC com esse artigo tenho certeza que você verá toda essa "magia" que o Rails aplica de outra maneira.
Se você gosta de assuntos como esse e quer ver mais conteúdos sobre padrões de projeto, não esqueça de deixar seu like e também sugerir um conteúdo.
Até a próxima!