MVC realmente é uma boa opção?

[Samuel Gomes_148425 19]

"O problema do MVC é que muita das vezes ele é vendido como vacina e dane-se o front-end"

 

Mas como assim dane-se o front end? nao entendi

 

Usar o mvc, prejudica em que no front?

[Enrico Pereira 299]

O MVC leva a você o pensamento de que a web é plana, e que só o MVC resolve tudo.

Eu achei um excelente artigo, infelizmente em inglês falando sobre isso: http://www.sitepoint.com/mvc-and-web-apps-oil-and-water/

[Andrey Knupp Vital 136]

Enrico, cadê o seu exemplo do qual eu pedi no GitHub ?

[Enrico Pereira 299]

Estarei providenciando, um simples exemplo de ler uma lista de produtos estática mesmo, usando AngularJS e Silex

[Andrey Knupp Vital 136]

Sem frameworks cara, quero ver no braço, assim como o MVC pode ser feito no braço.

Quero que me mostre o quão performático e vantajoso é usar REST pra substituir o MVC.

 

Abraços,

Fico no aguardo,

Vamos nos falando.

[Enrico Pereira 299]

Não é bem assim, vamos continuar usando arquitetura n-tiers, mas não MVC, o real MVC consiste nisso:

 

-> Usuário cria request

-> Servidor -> PHP -> FrontController -> Rota -> Action

-> Controller requisita a model

-> Joga para view e ela fica com código PHP manipulando a model, esse é o problema:

 

Você foca no back-end, hoje temos aplicações ricas e "real-time".

 

Vou usar frameworks, o Silex faz roteamento e manipulação de HTTP.

O AngularJS ajuda na manipulação do DOM.

Artigo da "casa": http://imasters.com.br/im_destaque/a-evolucao-do-mvc-para-rest/ sobre o assunto ;)

[Andrey Knupp Vital 136]

Cara, você tá se enrolando todo e causando confusão ...

 

 

Você foca no back-end, hoje temos aplicações ricas e "real-time".

 

Em qual momento eu citei real-time ? não estamos discutindo isso.

 

E porque focamos no back-end ? qual parte do front-end não fazemos com o MVC ? o que o MVC tem haver com o front-end ? o client não precisa saber de absolutamente nada que acontece no servidor, ele só espera a resposta para a requisição, ou não.

 

O que isso difere no REST ? o que o REST tem de mais ou de menos pra mudar isso ? e onde que REST é padrão de arquitetura ?

 

Abraços.

[Enrico Pereira 299]

Digo, muitas apps hoje são real-time, etc. Não estou falando somente sobre REST, REST seria um estilo arquitetural.

[Andrey Knupp Vital 136]

Digo, muitas apps hoje são real-time, etc. Não estou falando somente sobre REST, REST seria um estilo arquitetural.

O que tem de arquitetura em REST ?

 

E refaço as perguntas: Porque focamos no back-end quando usamos MVC ? qual parte do front-end não fazemos com o MVC ¬¬ ? o que o MVC tem haver com o front-end ? o client não precisa saber de absolutamente nada que acontece no servidor, ele só espera a resposta para a requisição, ou não

[Enrico Pereira 299]

NÃO É SÓ REST.

 

MVC é um carinha para organizar código, isso não resolve problemas, eu realmente não estou muito relacionado com MVC, mas o problema foi a pergunta do tópico, MVC não cura câncer, eu nem deveria ter começado a discussão.

 

Estou enrolado realmente, minha cuca não está funcionando bem.

[Andrey Knupp Vital 136]

Tá, e qual aplicação web tem câncer ? ¬¬

Só podemos resolver um problema, quando temos um problema.

 

O problema: separação de camadas.

A solução: MVC, não necessariamente eu preciso usar o ©, posso ter apenas MV, isso não deixa de falar que minha aplicação é MVC, ainda vou ter models e views.

 

Outra coisa é que não preciso ter uma "classe" qualquer sendo chamada de controller, meu próprio arquivo pode acionar models e views, e esse arquivo ser um controlador.

 

Refaço novamente as perguntas: Porque focamos no back-end quando usamos MVC ? qual parte do front-end não fazemos com o MVC ¬¬ ? o que o MVC tem haver com o front-end ? o client não precisa saber de absolutamente nada que acontece no servidor, ele só espera a resposta para a requisição, ou não.

[Enrico Pereira 299]

Veja o hangout e os artigos, explicam melhor do que eu. Eu já me confundi todo, esquece .

[hinom 5]

Entendo do que vc está falando..

 

esse conceito distorcido é um veneno.. provém da época do boom do mvc para linguagens e web e muitos na época criaram a confusão por não entender web corretamente e tentar implementar mvc para web. Principalmente os que vieram de linguagens não web e bitolados em OOP.

 

Algo semelhante ocorre com quem programa em linguagem web (asp, php, ruby) e tenta aprender java, c++, etc..

 

Veja um exemplo de um artigo confuso:

http://blog.iandavis.com/2008/12/06/the-web-is-rmr-not-mvc/

 

Outro ponto é, MVC nunca foi "vendido" ou mesmo apresentado com uma caixa de pandora. Isso é ridículo... Aliás, quem lhe apresentou dessa forma também está errado.

 

MVC é basicamente:

"The central ideas behind MVC are code reusability and separation of concerns" (wikipedia)

 

MVC não foi feito para web, obviamente..

Foi uma idéia que surgiu nos anos 1970 e desde então vem sendo usado.

 

Atualmente há outros conceitos que complementam o MVC. Veja bem que complementar não é substituir.

Voltanto um pouco ao artigo do link acima, sobre RMR,

Preste atenção que RMR cai no mesmo conceito MVC.. o sujeito apenas trocou os nomes e se embananou para argumentar..

O conceito RMR nada mais é que um MVC adaptado. Apenas trocou as letras..

 

 

Enfim.. na minha opinião o povo bitolado e confuso tenta criar novas "modinhas".

Dessa forma, de que adianta termos conceitos e padrões se os padrões e conceitos mudam o tempo todo.

Ontem era MVC, Hoje é HMVC, amanhã é RMVKGS, depois de amanhã é WTF_MVC_RMR_IM_CONFUSED..

 

Padrão é padrão.. se vc muda o padrão o tempo todo, deixa de ter um padrão.. fica desorganizado, despadronizado. O que é ilógico e incoerente, não?

 

Se tens um conceito de novo padrão, deve adotar uma postura menos técnica e mais business e apresentar isso como um projeto.

Caso contrário dificilmente conseguirá convencer as pessoas ou ao menos ter chance de que alguém estude e entenda a sua proposta.

Não é jogando pedra em outro que vc conseguirá convencer que o seu é melhor ou ao menos interessante.

 

 

Nota importante, não estou defendendo MVC. Por mim, se existir conceito melhor, então boa! Vamos aplicar.

[angelorubin 142]

Bom dia,

 

Duas coisas que o hinom disse quase responderam minha dúvida:

 

MVC é basicamente:

"The central ideas behind MVC are code reusability and separation of concerns" (wikipedia).

 

Pelo que entendi sobre a idéia central do MVC é que se ele não resolver (completamente os problemas do universo) pelo menos já ajuda com a separação dos interesses !

 

Só fiquei em dúvida quanto ao code reusability, creio que isso já existia desde procedural não? O que no caso ele resolveria relacionado a isso que eu não saquei?

 

Nota importante, não estou defendendo MVC. Por mim, se existir conceito melhor, então boa! Vamos aplicar.

 

Aqui cai exatamente no meu ponto, não existe nada melhor até o momento, seria isso?

[Enrico Pereira 299]

Arquitetura 3-tiers não significa MVC. Existem outros padrões também como MVVM e MVP.

[hinom 5]

Exatamente.. MVVM e MVP são exemplos de MVC aprimorados.

 

 

 

#34 ,

 

Um exemplo de reutilização de código.. vamos mostrar algo simples

 

 

if( isset( $_GET['field'] ) ){
    // outros tratamentos
}
if( isset( $_GET['field2'] ) ){
    // outros tratamentos
}
if( isset( $_GET['field3'] ) ){
    // outros tratamentos
}

imagine ter que repetir isso em tudo quanto é formulário..

 

para 1 ou 2 campos, tudo bem..

 

Mas imagine aí um formulário com 30 campos de tipos diversos e fragmentado em partes.

80% do seu script será para validação de entradas, as condicionais, etc.. São processos redundantes, os quais podem ser automatizados.

Você não se preocupa mais com esse tipo de coisa.. apenas foca o desenvolvimento no business model.

 

Essa parte é responsabilidade do controller.

As regras podem ser flexíveis, definidas no model.

O resultado se dá na view, apesar de que nem todos os casos terminam na view.

 

Importante também não confundir OOP com MVC.

O MVC pode ser aplicado mesmo em procedural.

 

Um exemplo demonstrado pelo criador do PHP, Rasmus Lerdorf:

http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html

[Enrico Pereira 299]

Acho que não importa que padrões vc está seguindo, se vc está usando OO, seguindo princípios S.O.L.I.D., DRY, KISS, YAGNI, SoC, tenho certeza que você fará um bom código. Independente de Patterns (Arquiteturais e "Design"). Princípios valem muito mais.

[angelorubin 142]

Exatamente Enrico, a minha maior preocupação é começar de uma forma sólida, eu sei que esses padrões não são regras definitivas e imutáveis, (própria procedural mostrou isso, alias nessa área sempre foi assim, evoluindo e melhorando), percebo alias que foram criados a partir de experiências diversas na área do desenvolvimento e que devem ser utilizadas/adaptadas de acordo com a necessidade.

 

Obrigado a todos pela ajuda.

[Henrique Barcelos 290]

Independente de Patterns (Arquiteturais e "Design"). Princípios valem muito mais.

 

Patterns nada mais são do que maneiras bem conhecidas de aplicar esses princípios.

 

_________________

 

Vou tentar dar um exemplo mais concreto, angeloburin.

 

Isso ocorreu numa empresa de um conhecido, eles trabalham com automação industrial e foram contratados por uma outra empresa para desenvolver um sistema de kanban eletrônico. Enquanto isso, uma outra empresa foi contratada para desenvolver um outro sistema não relacionado, mas que compartilhariam a mesma infra-estrutura.

 

Inicialmente, dentro dos requisitos, o servidor rodaria PHP e o SGBD seria o Informix (IBM). Ambas as empresas desenvolveram as aplicações e no dia da entrega, chegaram ao cliente e ele falou o seguinte:

- Olha, estamos tendo problemas com o Informix, gostaríamos de utilizar o SQL Server, é possível?

 

A empresa desse conhecido (que é formado na primeira turma de Engenharia da Computação da UFSCar - São Carlos, SP, de 1992) utilizava a arquitetura MVC (para um sistema web) e precisou de 3 horas para adaptar o sistema para suportar SQL Server, basicamente, o que alteraram foram peculiaridades do banco de dados e arquivos de configuração.

 

A outra empresa, ao que parece, era fã da programação macarrônica, se enrolou toda, levou mais de 1 semana pra fazer a migração. Já imagino que deveriam ter queries espalhadas por arquivos de visualisação, variáveis globais incontroláveis, etc.

 

Diante dessa situação, qual empresa ficou com uma imagem profissional melhor?

 

Difícil alguém desenvolver uma coisa que depois passa a ser amplamente utilizada que não traga mais benefícios do que problemas. MVC tem vários aspectos falhos, que não cabe aqui explicar, o principal é que o desenvolvimento se torna mais complexo, entretanto, a manutenção de um sistema em camadas é exponencialmente mais simples do que um em código spaghetti.

 

MVC não é a cura para o câncer, não vai resolver todos os seus problemas e essa nem é a proposta dele.

 

O único objetivo do MVC é a separação de camadas.

 

Eu já disse isso aqui e repito em letras garrafais:

DESIGN PATTERN NÃO É RECEITA DE BOLO!

 

Christopher Alexander, arquiteto, pai dos Design Patterns diz algo mais ou menos assim:

A beleza dos design patterns é o fato de que você tem uma solução para um problema recorrente e que você pode aplicá-los diversas vezes e nunca repetir a mesma solução.

 

E reparem que como arquiteto, ele provavelmente nunca pensou que algo assim pudesse ser tão utilizado na área de TI.

[angelorubin 142]

Olá Henrique,

 

Exemplo perfeito, é exatamente neste sentido que eu estava conduzindo minhas dúvidas (obrigado por dividir suas experiências), na verdade a resposta para a minha pergunta é: depende, pois padrões se aplicam a alguns problemas e a outros nem tanto, como você mesmo disse:

 

DESIGN PATTERN NÃO É RECEITA DE BOLO!

 

E separar as camadas em uma aplicação que é a proposta do MVC para web, (mesmo do meu ponto de vista de iniciante), vejo vantagens como você mesmo citou e exemplificou.

 

Obrigado.