Por que desenvolvedores PHP pensam que MVC é uma arquitetura de aplicação?

Eu já falei antes que MVC é um padrão de interface de usuário, e não uma arquitetura de aplicação. Mas por que os desenvolvedores PHP tem a ideia de que MVC é uma arquitetura de aplicação em primeiro lugar? (Isso pode se aplicar a todos os desenvolvedores server-side, e não apenas ao pessoal do PHP.)

Eu costumava pensar que MVC era uma arquitetura de aplicação. Mesmo depois de ler o POEAA do Fowler e vendo que MVC era para a interface de usuário, eu percebi que isso significava que eu estava fazendo “aplicações de interface de usuário”. Mas isso não estava muito certo; seria mais preciso dizer que eu estava misturando os elementos de interface do usuário com aplicação no núcleo.

Com base nessa experiência, eu acho que a razão pela qual MVC é confundido com uma arquitetura de aplicação é porque os desenvolvedores PHP geralmente começam com scripts de página. Em nossos primeiros scripts de página, combinamos todas os elementos em uma única bola de lama: consultas SQL são entremeadas com HTML, e a lógica de negócios é espalhada por toda parte. Até onde nós sabemos, a página de script em si é “a aplicação”. Mais tarde, à medida que mais funcionalidades são necessárias, nós adicionamos outra página de script e outra, e outra. Nós continuamos a ver a coleção de páginas de scripts como “a aplicação”.

Então, a medida que progredimos em nossa profissão, e começamos a aprender a organizar melhor o nosso trabalho, nós começamos a separar os diferentes elementos da “aplicação”. Quando começamos a separar os elementos, nós os separamos para fora da página de script, que vemos como “a aplicação”. Extrair a view da página de script significa extrair a partir da “a aplicação”. Separar o model da página de script em sua própria camada significa a separação da “aplicação”. Tirar a lógica do controller da página de script significa tirá-lo da “aplicação”. Então, é claro que Model-View-Controller é visto como uma arquitetura de aplicação – nós separamos os elementos da nossa aplicação de acordo com esse padrão, certo?

Exceto que, em retrospecto, não é. Um dos grandes saltos que temos que fazer é perceber que MVC é para a parte de interface de usuário de nossos sistemas, assim como escreveu o Fowler. Nós, no lado do servidor, achamos que a interface de usuário é HTML, CSS e JavaScript, mas não é. Em vez disso, a interface do usuário é HTTP Request HTTP e Response. Em outras palavras, o template não é a View.

Uma vez que damos esse salto conceitual, começamos a perceber que a camada Model é o ponto de entrada para “a aplicação”. É ai que “a aplicação” deve viver, ou pelo menos onde deve-se olhar como ela vive. O Controller deve fazer pouco, mas precisa ter a entrada do Request e passá-la para o Model; da mesma forma, a View não deve fazer nada além de juntar a Response usando a saída do Model.

Com essa ideia de MVC do lado do servidor, nós começamos a ver que muito do que está em frameworks MVC do lado do servidor é “demasiado”. Funcionalidade de framework que não está relacionada a apenas pegar a entrada a partir de uma Request e apresentar a saída através de um Response se torna completamente secundária, talvez até mesmo prejudicial para construir aplicações bem estruturadas – aplicações que são independentes de qualquer interface de usuário em particular.

Concluindo

O padrão MVC do lado do servidor, como descendente da arquitetura Model 2 da Sun, é tão distinta do padrão MVC do lado do cliente como se fosse algo completamente diferente. Percebi isso quando estava escrevendo meu livro sobre a modernização dos aplicativos legados, e pesquisas mais avançadas me levaram a escrever Action-Domain-Responder como uma alternativa web específica para MVC. Action-Domain-Responder coloca uma ênfase muito mais forte no HTTP Request e Response como elementos de interface do usuário. Se você está interessado em construir aplicações melhores, você pode querer ler sobre ADR e testá-la em seu próximo projeto.

***

Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6288

Powered by WPeMatico