sobre MVC

[unfear 0]

Olá, estou estudando MVC e desenvolvendo um framework para estudo mas estou esbarrando em várias dúvidas.

 

1 - Qual é o modelo mais correto (digo para o PHP), pois vejo vários UML/Fluxogramas diferentes, desde o Controller intermediando a View e o Model (View <-> Controller <-> Model) também tem umas que o fluxo é um looping, (View -> Controller -> Model -> View ) há casos onde o Model consegue enviar dados diretamente para o View ou vice-versa, segue abaixo alguns links destes exemplos:

 

http://www.thegraphicrecorder.com/wp-content/uploads/2012/09/Lynda-MVC-Sketchnotes.jpg

 

http://media02.hongkiat.com/ios-appplication-dev-part1/model-view-controller.jpg

 

http://www.yessdata.com/img/byprd/CH_36/C_3699/P_4755CT2053/mvc.gif

 

http://3.bp.blogspot.com/-KyWNL6EHcic/UUXzK3ZXRqI/AAAAAAAAGrE/RaXXJdEmpOw/s1600/Slide2.PNG

 

http://www.patterns-kompakt.de/patterns/images/model_view_controller_cn.png

 

http://carlalexander.ca/wp-content/uploads/2015/05/Model-View-Controller.jpg

 

Baixei vários frameworks para analisar e não há uma consistência, há framework que usa o controller como se fosse model, então fica difícil até de confiar.

 

Instintivamente, pelo PHP ser algo estático eu boto mais fé no primeiro modelo, onde explica que o Controller faz a intermediação do Model e do View, faz mais sentido quando a ideia é o reaproveitamento do código e encapsulamento, no final só a View ficaria exposta e toda a aplicação ficaria na Model, mas de fato não faço ideia, alguém poderia matar está dúvida.

 

2 - Agora uma dúvida mais para o final do framework, digamos que eu tenho uma classe de listagem de tabelas, o ideal seria eu gerar toda ela dentro do Model ou apenas pegaria os dados em array no model e jogaria para um segundo recurso na view para gerar essa tabela?

 

3 - E a última duvida, como eu poderia fazer para aplicar uma persistência de dados de um sessão, tipo carrinho de compras? devo invocar em cada Controller o carrinho? ou poderia adicionar o carrinho como recurso de um Model principal?

[Gabriel Heming 766]

1 - Um ponto que deve entender é o fato do MVC, apesar de ser uma arquitetura de três layers, tem como foco principal a View. O modelo apresentado que melhor define o MVC é o seguinte:

http://media02.hongkiat.com/ios-appplication-dev-part1/model-view-controller.jpg

 

Um controller conhece a model e a view. Uma view pode conhecer a model, mas o contrário não é verdade. Uma view não chama o controller, a view lança um evento que o controller captura (o que nós conhecemos como Request). E, apesar da model não conhecer uma view, a model pode alterar uma view através do lançamento de um evento. Entretanto, o responsável por capturar o evento fornecido é a view. Dessa forma, a model não tem conhecimento de quem tratou seu evento.

 

Além disso, existe uma tremenda divergência e mal entendimento entre as responsabilidades. Em muitos frameworks conhecidos, você encontrará o uso da Model apenas como um storage e a view apenas como um template layer. Sendo o controller o responsável por tratar os objetos vindos da model e enviá-los corretamente para a View. Esse conceito é errado.

 

Em um acesso tradicional, um controller apenas deve receber uma requisição e, então, enviá-lo realizar a conexão model -> view, se necessário.

 

Mas existem acessos "não tradicionais", quando não haverá uma view a ser exibida (principalmente em tratamento de serviços, web services) ou quando não haverá um storage a ser consultado.

 

2 - Tudo que é de responsabilidade de negócio, deve ser tratado na Model. Já o que é pertinente a exibição, trata-se na view. Entretanto, se você está criando um componente para auxiliar na exibição das tabelas, esse componente é externo ao MVC mas pertinente a sua aplicação. Nada impede de você ter seus pacotes personalizados, e o mais indicado é utilizá-lo como um pacote do composer.

 

3 - Orientado-se pelo fato de que é uma definição de negócio e, a sessão do carrinho, pode pertencer a um usuário, você pode ter duas abordagens:

- Uma model para usuário e uma para o carrinho. Não sendo necessário o usuário estar logado para utilizar o carrinho.

- Ou a model do usuário é responsável pelo controle do carrinho. Sendo somente possível usufruir do carrinho quando o usuário estiver logado.

 

Para que você não tenha que instanciar sempre o carrinho, você pode utilizar ele em um Registry ou, como alternativa B, definí-lo como um Singleton.

[unfear 0]

Obrigado por me trazer a luz :)