I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding.
I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one.
But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View.
I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.
Hmm..you are talking letting the view "change the values in the Model".
I thought "the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller" made it clear that I was talking about updating the view from the model, not vice versa.
In MVC, the controller initiates changes in the model, not the view. However, the view updates itself from the model.
Whether that's good or bad is a different story, but that's how MVC is defined.
Comments
I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding.
I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one.
But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View.
I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.
Hmm..you are talking letting the view "change the values in the Model".
I thought "the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller" made it clear that I was talking about updating the view from the model, not vice versa.
In MVC, the controller initiates changes in the model, not the view. However, the view updates itself from the model.
Whether that's good or bad is a different story, but that's how MVC is defined.
"But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View."
Definitely agree