And that's why I think those tutorials simplify things to a degree that confuses the newcomer.
Try to do a little "tabula rasa" and think the process from scratch, and decoupling the concepts.
First of all, MVC is a presentation layer. It does not (or should not) even know what is backing it up. It could be a database, an xml file, a text file, an in-memory collection, whatever. It should be abstracted away.
What does MVC understand? Receives an HTTP request, parses it using the route engine, resolves to the corresponding controller/action method and does whatever you write in the action method. End of the story.
Do you ask for an id which, behind the scenes, corresponds to a database surrogate key? MVC doesn't know that. For it, it's just an int parameter of a method.
It's entirely up to you how you decouple your logic and layers, how you retrieve data and check for security.
Assume you get asked for Products/Detail/1. Is your action method under authentication (using the authorize attribute)? If so, are your products only visible to certain users?
You'll pass to a business logic method the requested id along with the username, and that method will tell you "here's your product" or "sorry, you cannot view this" based on the logic inside. And heck, if you designed it well even the business logic method won't know if behind the scenes it used a database or anything else to retrieve the product.
I hope this little explanation clarifies things a little. MVC is just about handling HTTP requests and returning a view or some json data or whatever you want to return to the users. Anything that backs it should be abstracted away and implemented as you see fit.
The basic concept of MVC is to decouple the components (i.e. the model, view and controller).
The advantages of this approach are: less dependencies between the components; more flexibility; and when the design of your application changes, you only need to change the code in one location, not multiple.
For example, in Struts, all the configuration will be written in struts.xml
and mapping will be done in such a way that for every action there will be a result (JSP defined).
If you want to change the design or flow, you only have to change struts.xml.
Best Answer
The primary objective would be "separation of concerns", as the model, the view and the controller all have distinct responsibilities.
The author of the original Xerox PARC paper states that:
If unit-testing were the primary objective, one would be able to easily unit-test views. A look at the landscape of unit-testing projects/frameworks would reveal that it is quite contrary to the claim made. One would typically be using integration and functional tests to test the view.