Nice article, it sure helps!
However, as a CS student I have a couple of questions: Regarding the MVC pattern, in some university classes they told us that the model should give data to the view without going through the controller. As I see it, this collides with the structure you just mentioned above. Searching for it on the internet I realised that there is a wide range of MVC-based patterns.
Why should (or should not) exist this direct communication between model and view? What is the benefit of making the controller handle all the calls between the model and view?
Again, thanks for the article.
As a relative beginner myself I don't know how much insight I can offer, only that in the 2 Ruby based frameworks I've worked (Rails and Sinatra) that's how things are handled.
I see the Controller a the single point of reference in charge of collecting all the resources and sending them to the client. So it retrieves data from the Model, assembles it through the view, and sends it back as a response.
I'm sure there are other ways of doing it, and I hope to learn some of them as I go along :)
Hello! For my framework and my app skeleton, I implemented MVC pattern like you describe in your comment. Model give data to the View. The Controller, only filters user's input before passing it to model. I think that components should be at the same level but with a different role.
App and framework here: github.com/linna
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.