Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
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?
Obrigado por me trazer a luz :)
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:
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.