The problem is that the MVC pattern was designed in a system that doesn't really exist anymore. It was invented in Smalltalk at a time when UI libraries did not exist. To make a window dialog you drew all the boxes, highlighted the appropriate squares, made sure that the text you were drawing ended up in the right spot...etc...
Imagine what it would be like to write a dialog app using nothing but one large canvas. That's the world the MVC comes from.
A "view" in this system was a text box and it was a class that was responsible for drawing the box, the text, drawing selected areas, responding to changes in the text, etc...
A "controller" was another class that took mouse events that occured within this box like mouse moving, key down, key up, clicks, etc...and it would decide what happened. Should we change the text? Should we change the selection? Stuff like that.
A "model" was yet another class that represented the basic data and state of the component. A text box model would have the text of course, the font, selection, etc...
As you can see, in a situation like this the three components are very entangled in the representation of a single idea. It makes sense in this context to speak of a "triad".
Today, if you're working on creating a UI library and using raw drawing commands you might do something similar. But the application of the "MVC" pattern has spread beyond its initial purpose. Now days you have a "view" that may actually be a complete dialog, and a controller that's responding to events like "textChanged" or "buttonClicked". The model in today's MVC is normally something fairly disconnected from the system (but generally linked to the view by providing an observer interface of some sort) and there may be many views associated with the one model.
In a system I recently architected for example we had around 10+ views all observing a single document "holder" and its active document. A main drawing interface interacted with the layout of the document, various property views that observed the selected item and provided a record interface, and a smaller scale representation of the main view that showed the entire document instead of just the visible window. Some of these views had controllers of varying complexity that turned GUI events into changes to the document, which would in turn notify its various views.
Can you still call such a relationship a "triad"? Perhaps, but I think it implies too much of the former, older application of MVC.
Could you share controllers with different views? Depends on how similar the views are. I've found that generally speaking this type of object has behavior to specific to the view it's controlling AND the model it is manipulating to be very reusable...but there's always exceptions.
Might not be the best analogy but, think about the controller the same way as you would think about a spider's web. Its sole job is to catch flies (requests) for the spider (underlying layers) to digest. The web can catch and hold smaller or larger flies (models). A spider's web role is not to digest the prey, although it can be used in this purpose. The thinner and cleaner the web, the easier for the spider to make a living.
You could apply somewhat the same logic to your MVC application. The huge and nasty functions you describe are most likely behavior of the model and they should belong in the model (note that the model is not only the object that's being displayed in the view). If the behavior of the model changes it's the model that should be changed and not the controller that handles it.
Also, keeping them as private methods in the controller would only clutter it and make it hard to maintain. It also makes way for a bad habit, since other people that are involved in development would be tempted to do the same, since they've seen it done before in the project.
Best Answer
Things may seem to play out that way in some projects, but I wouldn't give any specific consideration to it.
A controller is basically a collection unit of semantically related methods (at least that's how I've always thought of them). That's probably not true all the time, but enough for government work, as the saying goes.
Many times, that tends to map somewhat closely to your "main business logic" classes, in that you tend to wind up with a controller for
Clients, another forStaff, etc.More often though controllers may tend to follow a context of what page(s) are being used. Working with a Clients page in the UI, for example, might also have relevant addresses to manage, in which case it can make sense to include an
Addresspost method in yourClientscontroller.But on the other hand, if you're using an API that's intended to be shared by multiple systems, such contexts aren't quite as applicable. In either case though, I don't think too many people would insist on having an
Addressescontroller to handle basic addressing needs of aClient. Make use of semantics and pragmatic grouping/contexts, and the two will go together (in fact, I might say that an Address for a Client might be submitted as part of a Client's POST/PUT operation, so maybe no need for a method to handle addresses, let alone its own controller)