Além do MVC [Pt.01] — Qual o problema do MVC?
Este post foca mais no uso do MVC no back-end web.
MVC é um padrão de arquitetura de software que foi descrito pela primeira vez em 1979, na época para Smalltalk. Ganhou popularidade e hoje é um dos design patterns mais conhecidos, e utilizados por desenvolvedores de várias áreas e plataformas.
Eu arriscaria dizer que MVC é um dos design patterns que melhor se encaixa para a “web comum”. É extremamente simples um programador entender essas três camadas: Model, View e Controller.
Em geral, e de modo nós temos: Um model para cada entidade/tabela do banco de dados, com seu respectivo controller com suas actions, e a view (html).
Uma coisa interessante de se observar é que nossa área (tecnologia da informação) é extremamente nova. Podemos traçar nossa profissão até aproximadamente 1960, ou seja, nossa profissão mal chegou a 60 anos, comparando-se a medicina, engenharia, arquitetura, física, matemática ou qualquer outra profissão estamos engatinhando.
Não apenas por ser recente, mas também pela sua natureza, desenvolvimento de software evolui e muda com muita velocidade. Não precisa ir muito longe para ver, muitos de nós ficam completamente perdidos com dezenas, talvez centenas de novas tecnologias que surgem todos os anos.
Mesmo no nosso dia-a-dia, onde não estamos criando o “novo facebook” recebemos noticias de novos frameworks e linguagens de programação.
Estamos amadurecendo, o mundo e os projetos que criamos estão diferentes. As necessidades e problemas de hoje podem ser bem diferentes dos de 1960.
Com isso em mente faço uma pergunta: E o MVC? Ainda são apenas três camadas? Seus projetos ainda seguem esse modelo?
Qual o problema do MVC?
Com o MVC nenhum. Os problemas que ele se propôs a resolver ele resolveu. Porém, os problemas agora são outros, e com eles várias outras soluções. Muitas apenas adicionando uma ou duas camadas a mais ao MVC, já outras se tornaram mais especializadas.
Pense! basicamente o problema que o MVC buscava resolver era organizacional, um padrão para facilitar a manutenção do projeto. Agora com projetos diferentes, mais complexos e maiores é natural que outros problemas apareçam.
POO Estruturado
Para muitos desenvolvedores Web/PHP POO é sinônimo de MVC. Um desenvolvedor de início de carreira ou simplesmente desleixado, que aprendeu que: “regras de negócio vão no controller”, apenas faz uma transcrição do que ele faria em uma programação estruturada para um método do controller.
Isso não é culpa do MVC, ele apenas determina que o controller que faz a comunicação entre a view e o model. Mais que isso é responsabilidade do desenvolvedor.
Nesse momento que começa a “gerra dos design patterns”.
Service, Repository, Entity, Driver, Adapter, ORM, Active Record entre outros, são alguns dos termos que você irá encontrar.
Fugindo da responsabilidade
Muitos desenvolvedores usam ou aprenderam MVC em conjunto com frameworks, alguns criaram seus próprios frameworks, mesmo esses se basearam nas estruturas MVC já existentes no mercado.
Basicamente são três pastas: models, views e controllers. No meio disso você podia possuir, ou não, sistemas de rotas, templates e abstração de banco de dados.
Estava tudo lá pronto e mastigado só esperando ser utilizado. Se o framework determinava que você acessava a database com uma camada de repository era isso que você usaria. O mesma vale para Entity, ORM, Active Record… Estava na “caixa” era só usar.
Para um desenvolvedor de início de carreira isso é extremamente compreensível. Já para desenvolvedores mais “vividos” isso é um “defeito” que eles deveriam resolver.
Como o código é organizado, é total responsabilidade do desenvolvedor. É tarefa dele usar as ferramentas (frameworks e mvc) para ter um projeto de qualidade.
Zona de conforto
Muitos desenvolvedores usam o MVC ou o framework como muleta para produção do seu código. É natural para os seres humanos se eximirem de responsabilidade, afinal ir além do MVC exige um certo nível de maturidade como desenvolvedor.
Se a ferramenta que você está usando não é boa, é seu dever como profissional parar de usa-la. E se você não pode parar de usa-la, também é seu dever encontrar uma solução dentro dela.
Existem tantos add-ons para o MVC, que você passa a se questionar se ele ainda é o MVC que conhecemos e amamos.
Nossa profissão muitas vezes exige muito do nosso tempo, porém se você é um apaixonado por ela (e eu espero que seja) você da um jeitinho de aprender sobre esses add-ons. Lembre-se que a tecnologia que você usa hoje, não será a mesma que você vai usar amanhã, mantenha-se atualizado para garantir seu emprego.
