MVC can mean a lot of different things, and the right answer probably looks like, "Whatever works with my framework and whatever else I am using or doing."
This is a topic where understanding history helps you understand why people do things the way they do them, what it means, and how the idea could evolve in the future. The last is important - if you can figure out how people will do things in 5 years, in 5 years you can have 5 years more experience doing it "the modern way" than anyone else! For a full version of the history, see http://c2.com/cgi/wiki?ModelViewControllerHistory.
Here is a summary. Originally MVC appeared for interactive applications. (I know this seems like a diversion, but this will matter.) Every single interactive component - every dropdown, etc, had its own model, view and controller. The job of all three was well defined. The Controller would have a set of possible events that could happen (someone clicked a mouse, pressed a key, another controller passed a message saying do something) that it was supposed to take care of. In turn it knew about a view and a model. The view knew how to draw itself (you were told to scroll down, select item #3, etc). And the model was in charge of the data that determined what was in the view (eg list of entries for a dropdown). Very, very granular. Lots of components. Lots of dynamic interactions.
MVC is still used this way for interactive applications.
Then the web came along. One thing programmers do when they move to a new domain is try to carry along existing patterns. MVC was a proven one. In the context of the web, the only event of interest is "request page X". Suppose that is a page where a user can edit their information. There is going to be a data model associated with it. Think "User object, with these fields". There is going to be a view. Think, "Template for how to show the user." You can even have different views for the same object - if I look at your home page I am allowed to see different information than you are.
So far, so good. Where is the problem? There are many. Here is a short list.
- Generating a dynamic web page is usually much more complex than handling a click of a button in an interactive application. Therefore each of the three components is doing a more complex thing than they would in the application case.
- It is unclear to people what belongs where. The same code can go in the model, view, and controller, and it is not immediately obvious that it matters where it lives. But random things tend to be particularly easy to insert into the controller.
- Complex web pages include multiple things that want data models - for example a form, a sidebar, ads, and so on. How do you represent that?
- Over a website you generally have many views, but you want to maintain a consistent view across them. How do you structure your views to allow this, while making them make sense for designers who are not programmers?
- Over time we're moving towards richer and more complex interactive pages, with tricks like AJAX. How do you shoehorn this into a per-page mentality that is natural when handling http requests?
And so on.
There are a lot of possible solutions to these, with different tradeoffs. In general if you use a framework, and try to solve things the way the framework expects, things work well. If not, well, then things get challenging. Hence my advice above to do whatever works with your framework.
But there are general principles.
Since controllers have a complex job to do, and are easy to insert additional logic into, the natural progression of code over time is that everything winds up in the all-knowing controller. Single large interacting blocks of code tend to not scale well. So you want to keep everything that can be kept out of the controller, out of the controller. (Some frameworks make things even simpler by splitting up controllers recursively!)
Business logic almost always belongs in the model. If you've got a database and an Object Relational Mapper, it is easy to structure models for simple applications as fairly straightforward layers over database tables. This is a popular design.
The view usually winds up being some sort of template system. How to handle commonalities is up to your template system. Understand the system you use, try to work within it.
You're a self-admitted beginner. I would highly recommend picking a framework, following advised best practices for said framework (even if you later decide they are not best, organizing code like your framework expects tends to be a path of least unexpected surprises), and getting practice with simple applications before tackling anything more complex. I highly, highly, highly recommend this - before trying to run, make sure that you're good at walking.
But as you walk, come back to this post, look at the list of pain points I gave above, think about your did or didn't hit them, and how you could handle them within what you built. This type of deliberate "how would I?" self-reflection is a critical part of improving. As I say, those are known pain points that come up across many different frameworks and I don't think that we've found the best way to handle them yet.
If I had to guess where we'll go, what do I think?
I think this in part because I have worked with a proprietary system that was structured this way. It was interesting. There were many controllers, views and models. However the controllers turned into data structures with some data inheritance to handle commonalities, the views into simple templates, and the models were parametrized by information from the controller. The concerns were so well separated that we were able to put the three into three different languages (Perl models, YAML controllers, TT templates). We were able to do things like completely rewrite the back end to the website (literally different pages, accessed in a different order, that were hitting different services) while managing to reuse, unchanged, most of the front end.
It was clear to me that that implementation was not exactly the right way to do it. But I think those ideas will be rediscovered multiple times, and over the next decade I think that is the direction that a lot of people will head.
(How did this answer get so long? Oh well, it is written, might as well post it.)