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.
I see another method that, unless I've misunderstood your post, hasn't been mentioned:
The main view, post, would have its model. This model would consist of ONLY the properties necessary to display this post (author,title,body, etc). Then, every piece of the post view that you can think of (timeline, tag navigation panel, subscribing panel, etc), would be split into their own views and each one would have its own model. This way, you can build up those models in your controller when you need them.
It might sound like an unnecessary amount of extra work to split these out like this, but it lends itself to the single responsibility principle. Keep each "view/model" focused on itself so that it can be re-used anywhere it is needed.
If you feel that your code is beginning to duplicate itself, which it might depending on your situation, you should consider writing some sort of "helper class." This helper class would handle all of the model build-up in one place, and all other duplicate code would be stripped down to a helper class call.
Best Answer
Try to change your viewpoint when you're thinking about this problem. A view doesn't have an action. An action returns a reference to a view. Multiple actions may return references to the same view, or actions may not return a response which isn't related to a view. That's the relevant part of an MVC pattern.
In MVC for ASP.NET, using the default ViewEngine, if an action returns a reference to a view (using
return View("ViewName")) then the framework searches first in a folder named after the Controller and then in a folder named "Shared", both in the application's View folder.So the question "If the view is in the Shared directory where would the controller for it go?" doesn't really make sense. What you should consider is that a view is put into the Shared directory so that it can be accessed by multiple controllers.