MVC for dummies: why should the controller send anything in the form?

Question

If I get this right than the function of the controller, it processes the POST data and technically makes changes to the state of the application (for example, the database) through the model.

As I understand it, View also gets data from the Model.

So this is how I understand the workflow:

Client request -> App Front Controller (if method = POST -> Controller ) -> View back to client

Here, Model used by Controller to read and write data and View to read data.

Thus, the controller is not used every time the page is loaded, in fact, only when application data is added / updated. In most cases, the controller shuts down.

So, why does almost every MVC resource say that the controller sends data to the views?

I am trying to write an application using the MVC pattern. Therefore, my applications always display data for the page from the Model. When the model is updated, I add a specific model update time to Memcache. At runtime, each scan looks at the latest update time (s) of the associated model (s), and the last time code for this view has been generated. If the model was updated before the cache was saved, review the read caches, otherwise it will be displayed again based on the updated model.

Answer 1

The controller is responsible for presenting views based on the requested data. This is there, so neither the model nor the view should know about the request. Yes, the view receives data from the model, but not always directly; the dispatcher may have to make some decisions depending on the request.

This is something like waiters in a restaurant so that they can take orders and serve dishes to customers. It is not the chefs who cause food after they are cooked; these are waiters. These are not customers who go to the kitchen asking for food; these are waiters who take orders, then let the chefs know what to prepare for whom. In the same way, the controller must handle client requests, whatever they are. This is a very crude comparison, but I hope you get the picture.

Answer 2

If I misinterpreted your question: the problem is that the view directly accesses the model. This should not happen because it defeats the reason for the MVC pattern. A view does not need to know anything about the model itself, so the model can be replaced with something else - the controller should provide data (in most cases it is flattened or projected) to the view.

If I: the controller never bypassed. Just because it does nothing with the data does not mean that it is not needed - it provides a layer of abstraction between the model and the view. The point is to be able to exchange the model without the need to adjust the view.

Answer 3

The controller never bypasses, because you need to specify which views are shown and what data (if any) is used in these views. Each request to receive or send to the MVC website uses a controller to control what is displayed or collected to / from the client.

In its core, MVC is used to separate problems. The model works with data, representations representations of representations and the controller provides logic between them.

Answer 4

If you are a person who learns faster on getter hands, dirty with codes or looking at something visual, like me ....

I suggest you follow the tutorial at railsforzombies.org . This pretty much explains all the basic ones using rails, including MVC. The tutorial mentions that if you put all this logic in, it will be random. The code will be a bit, because the guys who want to use your code will be confused by the codes. Putting all the logic in the controller and putting it in sight. This will be very clear to the person who is looking into your codes.

Answer 5

Answer 6

Typically, the controller uses the model and passes the past data to the view. The view must not see the Model. The main goal is to keep the view separate from the model!

Answer 7

MVC for dummies: why should the controller send anything in the form?

This is the main point of MVC: to create a free communication, dividing and distinguishing applications. You have a View, Model, and Controller that perform specific tasks.

Why separation is necessary because it is difficult to debug and fix one giant godzilla application. Imagine that you are fastening a car made of stone. There are no bolts. Everything is carved from a large rock. How hard it is to fix it if you just want to change the wheels. You will need to cut the stone itself.

The main task of the controller is to process requests and display the corresponding view. What a job it is. He likes to ask why the postman should send mail. Because it is his job.