MVC 傻瓜教程：为什么控制器必须向视图发送任何内容？
如果我明白这一点，那么控制器的功能就是处理 POST 数据，并在技术上通过模型更改应用程序的状态（例如数据库）。
据我了解，视图还从模型获取数据。
这就是我对工作流程的理解：
客户请求 --> 应用程序前端控制器 --> （如果方法= POST --> 控制器） --> 查看 -->回到客户端
这里Model被Controller用来读写数据，被View用来读取数据。
因此，控制器并不是在每次加载页面时都使用，事实上，仅在添加/更新应用程序数据时才使用。大多数时候控制器被绕过。
那么，为什么几乎所有关于 MVC 的资源都在谈论控制器向视图发送数据呢？
我正在尝试使用类似 MVC 的模式编写一个应用程序。因此，在我的应用程序视图中，始终从模型获取页面的数据。当模型更新时，我将特定的模型更新时间添加到Memcache中。在运行时，每个视图都会查找相关模型的上次更新时间以及该视图的上次缓存生成时间。如果模型在保存缓存之前更新，视图将读取缓存，否则根据更新的模型重新渲染。
If I get this right than function of the Controller is processing POST data and technically making changes to the state of the application (e.g. DB) via Model.
As far as I understand, 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 is used by Controller to read and write data and by View to read data.
So controller is not used every time the page is loaded, in fact, only when app data is added/updated. Most of the times Controller is bypassed.
Thus, how come almost every resource about MVC is talking about Controller sending data to views?
I am trying to write an app using MVC-like pattern. So in my app views always get data for the page from the Model. When Model is updated, I add specific model update time to Memcache. At runtime each View looks up last update time(s) of related model(s) and last time cache for this view was generated. If model was updated before cache was saved, view reads cache, otherwise re-renders based on updated model.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
控制器负责根据请求的数据呈现视图。它就在那里，因此模型和视图都不需要知道请求。是的，视图从模型获取数据，但并不总是直接获取；控制器可能还必须根据请求做出一些决定。
这就像餐厅里有服务员一样，他们可以接受顾客的订单并向顾客提供菜肴。饭菜做好后端上来的不是厨师，而是厨师。是服务员。不是顾客去厨房要饭菜，而是顾客去厨房要饭菜。服务员接受订单，然后让厨师知道为谁准备什么。同样，控制器可以处理客户端请求，无论其性质如何。虽然这是一个非常粗略的比较，但我希望你能明白。
The controller is responsible for presenting views based on the data that is requested. It's there so neither the model nor the view need to know about the request. Yes, the view gets data from the model, but not always directly; the controller may have to make some decisions as well depending on the request.
It's something like having waiters in a restaurant so they can take orders from and serve dishes to customers. It's not the chefs who bring out the meals after preparing them; it's the waiters. It's not the customers who go to the kitchen asking for meals; it's the waiters who take their orders then let the chefs know what to prepare for whom. In the same way, the controller is there to handle client requests, whatever their nature may be. It's a very rough comparison though, but I hope you get the picture.
除非我误解了你的问题：问题在于视图直接访问模型。这是不应该发生的，因为它违背了 MVC 模式的初衷。视图不应该知道有关模型本身的任何信息，因此模型可以交换为其他东西 - 控制器应该向视图提供数据（大多数时候是扁平或投影的方式）。
如果我这样做了：控制器永远不会被绕过。仅仅因为它不对数据做任何事情，并不意味着不需要它——它在模型和视图之间提供了一个抽象层。重点是能够交换模型而无需调整视图。
Unless I misinterpreted your question: The problem is with the view accessing the model directly. That's not supposed to happen as it defeats the reason for the MVC pattern. The view shouldn't know anything about the model itself, so the model can be exchanged for something else - the controller should supply the data (at most times it a flattened or projected way) to the view.
If I did: The controller is never bypassed. Just because it doesn't do anything with the data, doesn't mean it isn't needed - it provides a layer of abstraction between model and view. The point is to be able to exchange the model without having to adjust the view.
控制器永远不会被绕过，因为它需要指示显示哪些视图以及在这些视图中使用哪些数据（如果有）。对 MVC 站点的每个获取或发布请求都使用控制器来控制向客户端显示或从客户端收集的内容。
MVC 的核心是用来分离关注点。模型处理数据，视图处理表示，控制器提供两者之间的逻辑。
The controller is never bypassed as it is required to instruct which views are shown and what data (if any) is used in those views. Each get or post request to an MVC site uses the controller to control what is shown or collected to/from the client.
At its core MVC is used to separate concerns. The model works with the data, the views handle presentation and the controller provides the logic between the two.
如果你是一个像我一样通过代码或视觉内容学习得更快的人......
我会建议你按照 railsforzombies.org。它几乎解释了所有 Rails 的基本使用，包括 MVC。在教程中，它提到如果你把所有这些逻辑放在视图中，就会变得混乱。代码会有点混乱，因为想要使用你的代码的人会对代码感到困惑。通过将所有逻辑放入控制器中并将其输出到视图中。对于查看你的代码的人来说，这将是非常清楚的。
If you are a person that learn faster by getter hands dirty with codes or looking to something visual , like me ....
I will suggest you to follow the tutorial in railsforzombies.org . It pretty much explain all the basic using rails , including MVC. In the tutorial , It mention that if you put all those logic in view , It will be messy. The code will sux a little bit because the guys that want to use your code will be confused with codes. By putting all the logic in controller and output it in view. It will be very clear for the person that look into your codes.
通常Controller使用Model，并将处理后的数据传递给View。视图不应该看到模型。主要目标是 - 将视图与模型分开！
Usually Controller uses Model, and passes proccessed data to View. View shouldn't see Model. Main goal is - to keep View separately from Model!
这是 MVC 的要点：通过分离和区分应用程序的关注点来创建松耦合。您让视图、模型和控制器执行特定任务。
为什么需要分离，因为很难调试和修复一个巨大的哥斯拉应用程序。想象一下修理一辆石头制成的汽车。没有螺栓。一切都是从一块大石头上凿出来的。如果你只是想换轮子，那么解决这个问题有多难。您需要凿开岩石本身。
控制器的主要工作是处理请求并显示适当的视图。那是工作。这就像问邮递员为什么需要发送邮件一样。因为那是他的工作。
This is the main point of MVC: to create loose coupling by separating and distinguishing the application's concerns. You have the View, Model, and Controller doing specific tasks.
Why the need for separation because it's hard to debug and fix a one gigantic godzilla app. Imagine fixing a car made from stone. There are no bolts. Everything is chiseled from a big rock. How hard is fixing that if you just want to change the wheels. You will need to chisel out the rock itself.
The main job of the controller is to handle requests and display the appropriate view. That it's job. It's like asking why does the mailman need to send the mail. Because that's his job.