If there for example is an object "SoccerTeam" with a TeamView and a TeamController, and that team has a list of "Players". So there exists also an object "Player".
Does this object also need a "playerView" and a "PlayerController" ? If yes, should "TeamController" use "PlayerController" ? And should "PlayerView" update "TeamView" ?
Model-View-Controller basics
Model-View-Controller teaches you to separate concerns (3 concerns in its case). It doesn't teach how to communicate between those three concerns, what should talk to what, or even what should know about what. MVC is a very old design pattern that was created before we knew how to do any of that properly.
There are other things: observer pattern, n-tier architecture, plugins, that teach valuable lessons that could be useful here.
If there for example is an object "SoccerTeam" with a TeamView and a TeamController, and that team has a list of "Players". So there exists also an object "Player".
Does this object also need a "playerView" and a "PlayerController" ?
It's tempting to just think everything is an X and that you just need to write XModel, XView, and XController's for every X but it's not that simple.
A team is a collection of players. So the TeamView is an observer of every player. At least of every part of the players that are visible to the TeamView.
Nothing so far dictates that PlayerView even exists. It would be nice if it did because TeamView could simply aggregate PlayerViews rather than have to observe the players itself.
If yes, should "TeamController" use "PlayerController" ?
Well since Team aggregates Player it would be reasonable to make a Player method available to be called on the whole team. The Composite Pattern shows how to do that. Behavior such as "take a knee" is something only the coach should be allowed request. That logic doesn't belong in the model (which is about state) or the view (which is about presentation). And since the coach isn't going to want to ask each player individually we need to aggregate it at the team level.
teamView: Hey team controller: user says, take a knee. Get back to me whenever.
teamController: Well that user is the coach so he's allowed to do that. Hey playerControllers, take a knee.
playerController1: hey playerModel1, take a knee.
playerModel1: Knee taken. Back to you playercontroller1.
playercontroller1: Knee taken. Back to you teamController.
teamController: Next.
playerController2: hey playerModel2, take a knee.
playerModel2: I've got a busted leg so I'm just gonna lie here. Back to you playercontroller2.
playercontroller2: Got some error. Back to you teamController.
teamController: Whatever, Next.
...
teamController: Finished issuing take a knee. Back to you view.
teamView: Huh? Man the user has clicked on 5 different things while you were settling down. Just call me when the model's state updates. We're looking at cat video's now.
And should "PlayerView" update "TeamView" ?
Most likely no. Views should be absolutely as thin and free of any logic and knowledge as possible. Updates should come from the model as it's state changes.
