MVC realmente é uma boa opção?

[angelorubin 142]

Boa noite,

 

Estava assistindo o

sobre PHP e Orientação a Objeto aqui do imasters (muito bom por sinal), e durante um certo momento foi falado sobre o padrão MVC.

 

Notei que o pessoal participante em unanimidade não indica o uso, disseram não atender as necessidades reais da web atual entre outras coisas, gostaria de saber o por que e o que indicam para começar 'certo' com isso?

[Andrey Knupp Vital 136]

Cara, acho que você deve usar uma arquitetura que resolve o seu problema, pra mim é simples assim.

[Enrico Pereira 299]

Não, não é ideal. Pense em REST, REST é o presente e o futuro, mas REST (stateless, HATEOAS, HTTP, URI) de verdade não essas adaptações gambiarráticas, como a do Rails.

Cara, acho que você deve usar uma arquitetura que resolve o seu problema, pra mim é simples assim.

 

Concordo, mas o MVC não resolve nenhum problema.

[Henrique Barcelos 290]

Vejo casos reais de empresas que adotam arquiteturas específicas, dentre elas, o MVC, e garantem que faz sim MUITA diferença.

Sobre o MVC, a definição orginal dele não se aplica à web mesmo, mas com pequenas modificações que NÃO descaracterizam esse padrão arquitetural, dá sim pra utilizar MVC na web.

 

Edit:

REST não é padrão arquitetural. MVC resolve o único problema a que ele se propõe resolver: separar camadas coerentemente.

[Andrey Knupp Vital 136]

Enrico, eu, pelo menos eu, nunca vi REST como padrão de arquitetura, posso estar enganado, nesse caso, quero que você me mostre onde e como, além de me apresentar uma proposta que resolve o problema de separar a aplicação em camadas (coisa que o MVC faz) com REST.

 

Separando regras de negócio, de interface de usuário, etc etc.

[Enrico Pereira 299]

MVC usamos ele adaptado, com HMVC, outras camadas por cima, etc. MVC mascara o problema de separação de camadas (isso aplica-se a web somente).

 

REST é um estilo arquitetural, MVC não separa nada, vc tem lógica PHP na view.

 

REST basicamente:

API = Model

HTTP = Controller

HTML+ JavaScript (ajax) = View

 

Requisição parte do servidor para o HTML (usa-se PHP para rotear e comprimir HTML, CSS, JavaScript), o JavaScript faz consulta, com o protocolo HTTP (controller, mediador) para a API (model, regras de negócio) e manipula o HTML.

 

Claro que o HTML faz parte da API também, pois se não tem hipermídea (HATEOAS), não é Restful.

 

Essa palestra mostra muito bem sobre REST no lado cliente:

e essa como consumir com JavaScript:

 

Confesso que ainda estou aprendendo e no início também estranhei, mas hoje acho melhor.

[Andrey Knupp Vital 136]

Tá,

Primeira coisa é que não estamos falando de Client-Side e sim de Server-Side.

Segundo é que lógica você vai ter em qualquer lugar da aplicação, portanto não generalize as coisas, estou falando que o MVC separa a lógica de exibição, de apresentação ou como queira chamar, da lógica de interpretação de dados, de armazenamento, etc.

 

Segunda coisa é que não mencionei em momento algum HMVC.

Terceira coisa, é que você está confundindo, provavelmente o significado da palavra separação, causando algum mal entendido nas respostas trocadas.

 

Quarta e última coisa: HTML+ JavaScript (ajax) = View, porque AJAX ? o que REST tem haver com AJAX ? e porque apresentação de alguma coisa tem que ser consolidada em AJAX ?

[Henrique Barcelos 290]

MVC usamos ele adaptado, com HMVC, outras camadas por cima, etc. MVC mascara o problema de separação de camadas (isso aplica-se a web somente).

REST é um estilo arquitetural, MVC não separa nada, você tem lógica PHP na view.

 

Já ouviu falar de LÓGICA DE APRESENTAÇÃO? Se você REALMENTE utiliza o MVC dentro da sua proposta pra web, não vai ter nada mais que isso. A View não é uma camada totalmente burra, alguma lógica ela pode e DEVE ter.

 

REST = REpresetational State Transfer.

 

 

REST afirma que a web já desfrutou de escalabilidade como resultado de uma série de desenhos fundamentais:

• Um protocolo cliente/servidor sem estado: cada mensagem HTTP contém toda a informação necessária para compreender o pedido. Como resultado, nem o cliente e nem o servidor necessitam gravar nenhum estado das comunicações entre mensagens. Na prática, muitas aplicações baseadas em HTTP utilizam cookies e outros mecanismos para manter o estado da sessão (algumas destas práticas, como a reescrita de URLs, não são permitidas pela regra do REST).
• Um conjunto de operações bem definidas que se aplicam a todos os recursos de informação: HTTP em si define um pequeno conjunto de operações, as mais importantes são POST, GET, PUT e DELETE. Com frequência estas operações são combinadas com operações CRUD para a persistência de dados, onde POST não se encaixa exatamente neste esquema.
• Uma sintaxe universal para identificar os recursos. No sistema REST, cada recurso é unicamente direcionado através da sua URI.
• O uso de hipermídia, tanto para a informação da aplicação como para as transições de estado da aplicação: a representação deste estado em um sistema REST são tipicamente HTML ou XML. Como resultado disto, é possível navegar com um recurso REST a muitos outros, simplesmente seguindo ligações sem requerer o uso de registros ou outra infraestrutura adicional.

 

Ela define a representação dos RECURSOS de uma aplicação web, mas não envolve absolutamente NADA do backend, do que ocorre por debaixo dos panos. Para isso ele não resolve nada. Você pode ter um serviço REST funcionando bonitinho para o cliente, mas atrás disso, pode ter a zona que quiser no servidor.

 

Resumindo: REST serve apenas para a INTERFACE do seu serviço web.

 

Outro equívoco da sua resposta é dizer que Ajax faz parte da View. Ajax faz parte do Controller e pode conter partes do Model, mas View definitivamente não. O HTTP não é o controller, é UM protocolo utilizado para comunicação entre o controller do cliente (navegador) e o controller do servidor (sua aplicação).

 

A grande dificuldade de entender o MVC web é a insistência em se basear no MVC tradicional. No MVC tradicional só existe um único computador envolvido, no MVC web existem vários.

 

No servidor temos:

• Model: é o modelo da aplicação, dados, etc.
• Controller: servlets (no caso do java), scripts perl, scripts PHP
• View: é a saída HTML/XML/etc gerada.

 

No cliente temos:

• Model: dados de cache, session/local storage
• Controller: Navegador, javascript (incluso Ajax)
• View: o HTML renderizado na tela do navegador, listas, menus, botões

Além disso, podem existir intermediários de cache, sistemas distribuídos, cada um com uma parte do Model ou responsável por executar uma função específica do Controller.

 

Como nada é pra sempre, ainda mais em se tratando de computação, as coisas evoluem e já existe uma proposta para tentar melhorar alguns aspectos falhos do MVC. Alguns pesquisadores propuseram há 1 ou 2 anos atrás um padrão arquitetural chamado MOVE: Model, Operations, View and Events.

[Enrico Pereira 299]

Primeira coisa é que não estamos falando de Client-Side e sim de Server-Side.

 

Primeira coisa é que um não funciona sem outro. a web não é plana

 

Quarta e última coisa: HTML+ JavaScript (ajax) = View, porque AJAX ? o que REST tem haver com AJAX ? e porque apresentação de alguma coisa tem que ser consolidada em AJAX ?

 

Nada, mas precisamos fazer requisições via client side. Ajax requisita e manipulamos o DOM.

 

Segundo é que lógica você vai ter em qualquer lugar da aplicação, portanto não generalize as coisas, estou falando que o MVC separa a lógica de exibição, de apresentação ou como queira chamar, da lógica de interpretação de dados, de armazenamento, etc.

 

Certo, mas o mvc é colocado para curar o câncer.

 

 

 

Segunda coisa é que não mencionei em momento algum HMVC.

Terceira coisa, é que você está confundindo, provavelmente o significado da palavra separação, causando algum mal entendido nas respostas trocadas.

 

Quis mencionar sobre adaptações que fazemos nele para web.

 

Já ouviu falar de LÓGICA DE APRESENTAÇÃO? Se você REALMENTE utiliza o MVC dentro da sua proposta pra web, não vai ter nada mais que isso. A View não é uma camada totalmente burra, alguma lógica ela pode e DEVE ter.

 

Mas, veja, começa a criar várias camadas, lógica de apresentação, lógica de negócio e o inútil controller, sim o controller é inútil, a função dele é basicamente pegar a model e jogar pra view, nada além disso.

 

 

 

Ela define a representação dos RECURSOS de uma aplicação web, mas não envolve absolutamente NADA do backend, do que ocorre por debaixo dos panos. Para isso ele não resolve nada. Você pode ter um serviço REST funcionando bonitinho para o cliente, mas atrás disso, pode ter a zona que quiser no servidor.

 

Sim, mas não podemos colocar tudo em client side ou no server side, a web evoluiu: não é mais aquela de "ah, sou backend, fiz minha lógica, agora foda-se o front, ele vê aí os bagui".

 

 

 

Resumindo: REST serve apenas para a INTERFACE do seu serviço web.

 

NÃO! REST não é só para webservices.

 

 

 

Outro equívoco da sua resposta é dizer que Ajax faz parte da View. Ajax faz parte do Controller e pode conter partes do Model, mas View definitivamente não. O HTTP não é o controller, é UM protocolo utilizado para comunicação entre o controller do cliente (navegador) e o controller do servidor (sua aplicação).

 

 

Não pense na organização do client em si. Esse foi meu problema para compreender também.

 

REST é HATEOAS (Hypermedia as the Engine of Application State).

 

Bem, vamos lá:

 

Usuário requisita /produtos

 

Sua API response a página com o HTML, já que os browsers usam no Accept o text/html, você vai responder com HTML.

 

No HTML, você inclui javascript, javascript vai requisitar a API com Accept: text/xml ou application/json e vai pegar o retorno, com os dados ele manipula o DOM, mostrando informação ao usuário.

 

Veja:

 

Browser requisita: -> Retorna a View.

Javascript cria requisição HTTP para a model (API com xml/json/outros): -> HTTP é o intermediário, controller, a model é a própria API.

 

Bem, é difícil entender isso, acho que não expliquei bem, mas tentei ao máximo hehe.

 

 

 

A grande dificuldade de entender o MVC web é a insistência em se basear no MVC tradicional. No MVC tradicional só existe um único computador envolvido, no MVC web existem vários.

 

Vejamos:

 

X é projeto para ambiente A

surge o ambiente B

X é adaptado para o ambiente B

 

O X do ambiente B continua sendo X?

 

MVC não existe na web, pelo seguinte:

 

A WEB NÃO É PLANA! Temos lado cliente e lado servidor, punto e basta, um não vive sem o outro.

Em desktop não temos isso.

 

 

 

No servidor temos:

• Model: é o modelo da aplicação, dados, etc.
• Controller: servlets (no caso do java), scripts perl, scripts PHP
• View: é a saída HTML/XML/etc gerada.

 

No cliente temos:

• Model: dados de cache, session/local storage
• Controller: Navegador, javascript (incluso Ajax)
• View: o HTML renderizado na tela do navegador, listas, menus, botões

Além disso, podem existir intermediários de cache, sistemas distribuídos, cada um com uma parte do Model ou responsável por executar uma função específica do Controller.

 

Eu não quis falar nesse sentido.

 

 

 

Como nada é pra sempre, ainda mais em se tratando de computação, as coisas evoluem e já existe uma proposta para tentar melhorar alguns aspectos falhos do MVC. Alguns pesquisadores propuseram há 1 ou 2 anos atrás um padrão arquitetural chamado MOVE: Model, Operations, View and Events.

 

Veja Resource-Method-Representation (MVC), criado em 2008, para arquitetura REST, inclusive existem frameworks em PHP e outras linguagens que implementam ele.

[Andrey Knupp Vital 136]

Olha, nem vou seguir com essa discussão inútil e fora de contexto porque alguém aqui já tá falando coisa que não tem absolutamente nada haver.

 

Entretanto, Enrico, me manda um repositório seu no GitHub, com uma implementação em PHP de tudo isso que você disse.

Eu quero ver a forma que você transpõe isso em código, quero ver como é feito, e quero ver no final das contas, o quão performático e vantajoso isso é.

 

Se não tiver, sinceramente, faça um, não custa nada, não é pra criar uma aplicação, mas sim algo simples como uma listagem de produtos, como você mesmo citou.

 

Veremos na prática,

Abraço.

[Henrique Barcelos 290]

Primeira coisa é que um não funciona sem outro. a web não é plana

Faço uma aplicação web com session/local storage rodando apenas no cliente, e aí?

 

NÃO! REST não é só para webservices.

Qualquer aplicação web é um "serviço web".

 

A WEB NÃO É PLANA! Temos lado cliente e lado servidor, punto e basta, um não vive sem o outro.

Em desktop não temos isso.

 

Exatamente por isso que eu citei o fato de existir uma tríade MVC em cada componente da arquitetura web (clientes e servidores). O que une os componentes é justamente o HTTP. Dessa forma, na web, o Controller fundamentalmente lida com requisições e respostas HTTP.

 

Eu poderia ficar aqui apontando cada erro conceitual das suas respostas, mas não vou conseguir te convencer de nada mesmo, melhor nem gastar o meu e o seu tempo e não floodar o tópico.

[Andrey Knupp Vital 136]

Perfeito @Henrique, bem lembrado das API's de Local/Session Storage, fora WebSQL e IndexedDB que são API's bem bacanas que permitem criar facilmente aplicações web sem depender de Server-Side em qualquer ponto.

 

Tinha esquecido de mencionar as mesmas, fora outros recursos que o próprio HTML5 já fornece pra serviços externos de terceiros, Web Intents.

 

Entre outras coisas.

Entretanto [+1].

[Enrico Pereira 299]

A web já possui um MVC:

 

Model: servidor

Controller: HTTP

View: HTML, CSS, JS

 

Primeira Requisição cai na view, a cada interação do usuário, o javascript requisita a model (o servidor), e o controller disso é o HTTP.

 

A diferença é que o MVC de verdade ele não é aplicável na web, já que o MVC tradicional não tem a riqueza que a Web tem.

 

Na prática não ficaria tão diferente, a diferença estaria na comunicação cliente-servidor. O back-end não seria o deus da aplicação como é geralmente.

 

 

 

Faço uma aplicação web com session/local storage rodando apenas no cliente, e aí?

 

Verdade, me equivoquei, mas o back-end não faz sozinho o que o front-end faz, principalmente com RIA (rich internet application).

 

 

Exatamente por isso que eu citei o fato de existir uma tríade MVC em cada componente da arquitetura web (clientes e servidores). O que une os componentes é justamente o HTTP. Dessa forma, na web, o Controller fundamentalmente lida com requisições e respostas HTTP.

 

Eu poderia ficar aqui apontando cada erro conceitual das suas respostas, mas não vou conseguir te convencer de nada mesmo, melhor nem gastar o meu e o seu tempo e não floodar o tópico.

 

Na verdade sim, o que você está falando eu concordo, mas isso não é MVC, não que seja ruim, mas MVC não é isso pois ele foi feito para ambientes planos.

[Henrique Barcelos 290]

Model: servidor

Controller: HTTP

View: HTML, CSS, JS

 

Tá errado.

 

HTTP não é controller, são as mensagens passadas entre controllers.

JS não é View, faz parte do Controller.

 

A diferença é que o MVC de verdade ele não é aplicável na web, já que o MVC tradicional não tem a riqueza que a Web tem.

 

Padrão arquitetural não é receita de bolo! Arquiteturas são influenciadas por 3 coisas:

• Experiência do programador
• Regras de negócio
• Entorno tecnológico

Se o sistema é web, a arquitetura será de um jeito, se é desktop simples, será de outro, se é distribuído, outro jeito.

 

Na verdade sim, o que você está falando eu concordo, mas isso não é MVC, não que seja ruim, mas MVC não é isso pois ele foi feito para ambientes planos.

 

Pode não ser o MVC tradicional, proposto por Trygve Reenskaug, mas segue a mesma estrutura, ADAPTADA para o contexto web.

 

Tudo o que você falou pode fazer sentido pra você na teoria, mas põe na prática pra ver:

 

Entretanto, Enrico, me manda um repositório seu no GitHub, com uma implementação em PHP de tudo isso que você disse.

Eu quero ver a forma que você transpõe isso em código, quero ver como é feito, e quero ver no final das contas, o quão performático e vantajoso isso é.

[Enrico Pereira 299]

HTTP é o controller das requisições. Como a comunicação web funciona??? Requisições HTTP. Não estou falando de client ou server diretamente, mas sim da arquitetura de comunicação.

 

JS faz parte da view com HTML, junto com CSS, assim como o Flex também pode ser, o Flash, Silverlight, um vídeo, uma imagem, etc.

 

 

 

 

Padrão arquitetural não é receita de bolo! Arquiteturas são influenciadas por 3 coisas:

• Experiência do programador
• Regras de negócio
• Entorno tecnológico

Se o sistema é web, a arquitetura será de um jeito, se é desktop simples, será de outro, se é distribuído, outro jeito.

 

Claro, não podemos falar arquitetura X é um lixo, mas podemos discutir, criticar, elogiar arquitetura X.

 

 

 

Pode não ser o MVC tradicional, proposto por Trygve Reenskaug, mas segue a mesma estrutura, ADAPTADA para o contexto web.

 

Tudo o que você falou pode fazer sentido pra você na teoria, mas põe na prática pra ver:

 

Veja qualquer aplicação feita em ExtJS com REST.

[Henrique Barcelos 290]

Bom, vou me retirar da discussão, não vai levar a lugar nenhum.

[Enrico Pereira 299]

Bom, vou me retirar da discussão, não vai levar a lugar nenhum.

 

Não vai levar mesmo, a pergunta foi abstrata demais, seria como "A maçã é realmente gostosa?". Isso é relativo e varia de caso para caso.

[hinom 5]

Ao Enrico, desculpe mas não concordo com suas justificativas.

Você está com uma noção errônea sobre o que é MVC e pior, fazendo confusão com protocolos e "infra-estrutura".

 

Não preciso explicar o que é MVC ou contra-argumentar pois o Henrique explicou muito bem.

 

Tentei mesmo entender a sua "proposta", mas, a partir do post #6 achei estranho as suas argumentações.

O que matou mesmo foi o post #13...

 

 

 

A web já possui um MVC:

Model: servidor
Controller: HTTP
View: HTML, CSS, JS

Control -> é o motor do sistema, controla as requisições, librarys, etc. E faz o papel de comunicação entre model e view.

 

Model -> é onde aplica-se o modelo de negócios.

View - > output

 

 

Você misturou um mecanismo com outro.

Vamos usar um carro como analogia:

 

Control -> motor do carro

Moldel -> motorista

View -> podemos dizer que o movimento das rodas faz parte da view, mas veja que a roda não pode ser burra. Há um controle que provém do model.

A luz do farol também faz parte da view, é um output.

A buzina também.

 

Segundo o seu conceito:

 

 

Control -> motor do carro A estrada, os semáforos

Moldel -> motorista combustível (diesel, gasolina, alcool, etc)

View -> A luz do farol também faz parte da view, é um output.

A buzina também.

 

 

Entendeu a confusão que está fazendo ?

[angelorubin 142]

Realmente notei que o tema é polêmico, não era minha intenção polemiza-lo ainda mais e sim entender se o MVC realmente ajuda a organizar ou é apenas uma 'moda' que acaba piorando as coisas quando se chega a um determinado ponto de crescimento da aplicação?

 

Porque no final das contas é uma forma de organizar ou pelo menos imaginou-se resolver este tipo de problema ao cria-lo, entretanto penso eu (ingenuamente talvez) que seja importante para qualquer aplicação tal tipo de solução.

[Enrico Pereira 299]

Ele pode organizar sim, mas organizar não resolve problema, eu vi o hangout e os argumentos contra o MVC contidos nele são ótimos.

 

A web funciona a partir de Request/Response, quem faz isso é o HTTP, eu estava falando sobre arquitetura cliente-servidor, não só cliente, nem só servidor. O problema do MVC é que muita das vezes ele é vendido como vacina e dane-se o front-end, etc.

 

Em desktop ele é vacina, pois não há comunicação em dois níveis como temos na web, desktop é plano.

Claro, você usa uma espécie de MVC no server e no cliente, mas eles são separados, o cliente (HTML, JS, Flex, Flash) pode criar requisições na model, que seria um web service.

Eu sei, é complicado entender isso, eu achei também quando comecei a ver "MVC sucks" e fui pesquisar sobre o assunto.