在 mvc 中提供错误页面：控件还是视图？
让我们首先了解 Web 上有关 MVC 的相同页面。该控件接收请求，选择视图，发送从视图获得的响应。 （也许控件从模型获取数据，也许视图自己获取数据，我不在乎。）可能会发生错误，因此我们希望处理错误并向浏览器显示消息或错误页面。
我正在尝试确定这些错误消息/页面是控件的一部分还是来自视图。也许对于不同类型的错误它是不同的。
一些例子：
- 请求路径没有意义，因此我们希望使用自定义的“未找到”页面进行响应。
- 控件选择“未找到”视图并使用其响应
- 控件自行构建“未找到”页面
。
- 控制器成功选择视图，但视图抛出异常。
- 该视图返回错误状态。控制器检查状态，然后选择一个新视图并使用其响应
- 该视图返回错误状态。控制器自行构建错误响应。
- 视图处理异常并向控制器返回有效的错误页面或消息。控制器盲目地将其作为响应发送。
现在，这两种情况下前两个选项之间的区别是技术/组织上的，并且对用户来说可能没有区别。 对此有标准意见吗（也许跨 MVC 框架）还是选择只是任意的？首选方法是什么？
Let's start by getting on the same page about MVC on the web. The control receives requests, selects a view, sends a response that it gets from the view. (Maybe the control gets data from the model, maybe the views do it themselves, I don't care.) Errors can occur, so we want to handle the errors and display a message or error page to the browser.
I'm trying to decide if these error messages/pages are part of the control or come from the view. Perhaps it is different for different kinds of errors.
some examples:
- The request path is meaningless, so we want to respond with a custom "not found" page.
- The control selects the "not found" view and uses its response
- The control builds the "not found" page itself
.
- The controller selects a view successfully, but the view throws an exception.
- The view returns an error status. The controller checks the status and then selects a new view and uses its response
- The view returns an error status. The controller build the error response itself.
- The view handles the exception and returns a valid error page or message to the controller. The controller blindly sends it as the response.
Now, the difference between the first two options in both cases is technical/organizational, and there is probably no difference to the user. Is there a standard opinion on this (perhaps across MVC frameworks) or is the choice just arbitrary? What is the preferred method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果遵循 MVC 设计模式，这种情况应该永远不会发生。视图中应该包含的唯一逻辑只是显示逻辑（格式化、本地化等）。
错误应该在模型或控制器级别捕获，但由控制器决定如何处理用户（重定向/404/等）。
编辑：
当然这不是唯一的方法..我确信您可以在各处找到做不同事情的被黑客攻击的、混蛋的代码。就我而言，是的 - 您的视图应该以不需要捕获错误的方式设计（除了 ajax/javascript 错误，但这就是它们所属的地方）。
我通常将其设置为对于要处理的每个 HTTP 错误代码都有不同的视图，并有一个用于包罗万象的通用视图。在这种情况下，控制器将负责将错误数据传递到视图进行渲染（通常作为数组）。当然，这也可以使用 ErrorModel 来完成（这将是实现它的“正确”方法 - 我只是懒惰;））
If the MVC design pattern is followed, this should never happen. The only logic that should be contained in a view is solely display logic (formatting, localizing etc).
Errors should be trapped either at the model or controller level, but it's up to the controller to decide what to do with the user (redirect/404/etc).
Edit:
Of course it's not the only way.. I'm sure that you can find hacked up, bastardized code all over the place that does different things. As far as I'm concerned, yes - your views should be engineered in such a way that errors will not need to be trapped (other than ajax/javascript errors, but that's where they belong anyway).
I usually set it up so that I have a different view for each HTTP error code I want to handle, and a generic one for a catch-all. The controller will be responsible in this case to pass the error data to the view for rendering (usually as an array). Of course, this could also be done using an ErrorModel (which would be the 'correct' way of implementing it - I'm just lazy ;))
我采取的方法是允许控制器处理您的第一种情况（基于路由的错误）。任何未经授权或格式不正确的请求都由呈现适当错误视图的“静态内容”控制器进行管理。
对于第二类错误 - 我不确定视图如何/是否可以与控制器通信它抛出了错误。我实际上很想看看其他人的意见，因为据我所知，如果视图遇到错误，则由视图来处理。
The approach I take is to allow the controller to handle your first case (route based errors). Any request made that is either unauthorized or poorly formed gets managed by a "static content" controller that renders the appropriate error view.
For your second class of errors - I'm not sure how/if the view can communicate back to the controller that it's thrown an error. I'm actually interested to see other's opinions, because as far as I know if a view encounters an error, it's up to the view to deal with it.