在视图中检索模型数据正确还是仅在控制器中检索模型数据正确？
我有一个 MVC 应用程序，通常让控制器传递视图所需的所有内容。但是，当我的视图嵌套在其他视图中时，必须将这些变量转发到嵌套视图是很痛苦的。
事情就是这样，还是我应该允许嵌套在视图中的部分/片段从模型中检索数据？
例如，我有一个在多个嵌套部分/片段中使用的状态列表。每次我只想在这些视图中的嵌套部分/片段上使用它们时，我都必须通过我的视图传递此列表。看起来很容易出错，而且感觉不太DRY。
I have an MVC application and I typically have the controller pass everything needed by the view. But when my views are nested inside of other views it's a pain to have to forward these variables on to the nested view.
Is that just how it is, or should I allow my partials/fragments nested inside my views retrieve data from the Model?
As an example, I have a list of states that I use in several nested partials/fragments. I have to pass this list through my views every time I want to use them only on nested partials/fragments in those views. Seems like it's prone to error and it feels not very DRY.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
View直接从Model读取是完全有效的。
查看维基百科文章或 Martin Fowler 的图片： http://martinfowler.com/eaaCatalog/modelViewController.html
It is perfectly valid for View to directly read from the Model.
Look at wikipedia article or at a picture by Martin Fowler: http://martinfowler.com/eaaCatalog/modelViewController.html
视图永远不应该直接访问模型。事实上，MVC 范例的全部要点是每个组件彼此松散耦合。因此您可以轻松地交换您的模型或视图。如果将模型代码放入视图中，则无法做到这一点。
助手或其他模块往往会减轻这些情况下的痛苦。我建议调查一下这些。还有“胖模型，瘦控制器”的概念，将更多内容放入模型中，以便更轻松地访问多个控制器之间共享的数据。
最后，这取决于你。 MVC 界限可能会变得模糊。然而，在我看来，直接从视图访问模型违反了核心概念。
The View should never have direct access to the Model. In fact, the whole point of the MVC paradigm is that each component is loosely coupled with the other. So you can swap our your Models or Views easily. You can't do that if you put Model code in your View.
Helpers or other modules tend to ease the pain in these situations. I would suggest looking into those. There is also the concept of "Fat Models, Skinny Controllers", putting more in your Model so it is easier to access data shared across multiple Controllers.
In the end, it's up to you. MVC lines can get blurred. However, IMO, accessing the Model directly from the View violates the core concepts.
将主应用程序逻辑拆分到几个小型 MVC“小部件”（控制器）上，其中每个“小部件”都有自己与模型的关系和自己单独的视图。然后，在执行应用程序期间，您可以在运行时执行小部件，并传递到主模板“READY 小部件视图”。
这里描述了类似的事情：
http://en.wikipedia.org/wiki/Presentation-abstraction-control
优点：
IMO，它比从
视图）
通常由应用程序逻辑/用例组成的代码库
独立小部件（每个小部件都有自己的模板）中描述的
更容易测试
Split main applogic on several small MVC "widgets"(controllers), where every "widget" has own relation to Model and own separate View. Then, during execution aplication you can just execute widgets in runtime, and pass to main template "READY widget views".
Something like that is described here:
http://en.wikipedia.org/wiki/Presentation-abstraction-control
advantages:
IMO, its much better than call Model from
view)
codebase by usually applogic/use cases
described in stanalone widgets (where each has own template)
more easy to test
如果您担心应用程序的速度性能，并且希望使其更简单，我会说您允许视图从模型中读取数据（只读）。当控制器和视图必须同步时，情况会更加复杂。视图需要的数据和控制器应该提供给视图的数据。当视图可以直接访问模型时，您不需要验证控制器是否提供此数据。
关于MVC概念是基于松耦合的说法，并不矛盾，因为模型仍然是独立的，不依赖于视图或控制器。控制器和视图之间的区别在于控制器既可以向模型推送也可以从模型拉取，而视图只能从模型拉取。
If you are concerned about speed performance of your app, and you want to make it more straightforward, I would say you allow views to read data from the model (read only). It is more complicated when both controllers and view must be in sync re. data that views need and controllers should provide to views. And when views can access model directly, you don't need to verify that controllers provide this data.
In regards to the argument that MVC concept is based on loose coupling, there is no contradiction as Model is still independent and does not rely on views or controllers. And the difference between controllers and views are that controllers can both push and pull to (from) the model, and views can only pull from the model.