I disagree with your diagram of model-view-controller. Traditionally, the view and the controller are both part of the user interface, so should be on the top part of your diagram. In fact the controller is
higher level than the view.
The distinction between these two parts is that the view is just a display of the data (model) whereas the controller is a way for the user to edit it. This was more relevant back in the 1970s where these things were more often separate. For a modern(ish) example, think of Vim's separation between the main display of your text file (the view) and its command line at the bottom (the controller). In most modern GUIs this distinction is meaningless, so you would group controller and view into the view and have a simple overall model-view separation.
Now I'm not saying that all of the classes you've called (something)Controller should be moved to the UI, I'm just saying that they're misnamed (at least by the traditional definitions). I think that your interpretation of model vs controller is raw model data vs non-graphical operations that act on them. But operations on the data are just as much part of the model as the data itself. For example, if I have a word processor then my model is a document, including operations on it. If I want to update the document programmatically (bypassing the GUI), for example to add a word, then I expect to call a method of the model. This should do everything to keep the model consistent, such as returning an updated word count. But that still doesn't need anything called a controller.
I just said that I'm not telling you to move your controller classes to the UI (view) layer. But that's a general comment about the meaning of "model view controller". The specific example you present on that page is "MenuModel" and "MenuController". These sound like things that both belong in the UI layer. Going back to the word processor example, your model might have a SaveToFile() method (although it would expect a file name parameter - popping up a save file dialogue box is the UI's job). But it won't know whether that came from a File->Save menu item or the user hitting ctrl+S. It's the UI's (view's) job to create a menu, choose what commands go on it, and map the OnClick events to actions on the model.
No doubt others will disagree with my understanding of the definition of "controller". This is the one thing you can be really sure about with that term! And it's another good reason to avoid it. Everyone agrees with "model" and "view" mean, so if you use those terms then people will know what you mean, but if you describe something as a "controller" then it just causes confusion.
The distinction between these two parts is that the view is just a display of the data (model) whereas the controller is a way for the user to edit it. This was more relevant back in the 1970s where these things were more often separate. For a modern(ish) example, think of Vim's separation between the main display of your text file (the view) and its command line at the bottom (the controller). In most modern GUIs this distinction is meaningless, so you would group controller and view into the view and have a simple overall model-view separation.
Now I'm not saying that all of the classes you've called (something)Controller should be moved to the UI, I'm just saying that they're misnamed (at least by the traditional definitions). I think that your interpretation of model vs controller is raw model data vs non-graphical operations that act on them. But operations on the data are just as much part of the model as the data itself. For example, if I have a word processor then my model is a document, including operations on it. If I want to update the document programmatically (bypassing the GUI), for example to add a word, then I expect to call a method of the model. This should do everything to keep the model consistent, such as returning an updated word count. But that still doesn't need anything called a controller.
I just said that I'm not telling you to move your controller classes to the UI (view) layer. But that's a general comment about the meaning of "model view controller". The specific example you present on that page is "MenuModel" and "MenuController". These sound like things that both belong in the UI layer. Going back to the word processor example, your model might have a SaveToFile() method (although it would expect a file name parameter - popping up a save file dialogue box is the UI's job). But it won't know whether that came from a File->Save menu item or the user hitting ctrl+S. It's the UI's (view's) job to create a menu, choose what commands go on it, and map the OnClick events to actions on the model.
No doubt others will disagree with my understanding of the definition of "controller". This is the one thing you can be really sure about with that term! And it's another good reason to avoid it. Everyone agrees with "model" and "view" mean, so if you use those terms then people will know what you mean, but if you describe something as a "controller" then it just causes confusion.