A new look at an old analogy
I was recently asked to describe the common components of web application frameworks. What purpose does eac...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
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 :)
Nicely desribed and written. Everytime i read an article about MVC i always wondering the 'What is the benefit of separating each component from the others?' part and each time i lost in the technical details and description. It'sā a really helpful. Thank you.
Glad I could help!
Separation of concerns is so important!
Good analogy, fun read, thanks!
Thank you!