【问题标题】:MVC - Datasource container in the viewMVC - 视图中的数据源容器
【发布时间】:2026-01-09 21:55:01
【问题描述】:

在干净的 MVC 中,我会从数据库中收集数据并将其传递给要呈现的视图。

即使视图逻辑选择不渲染某些元素。这就提出了以下问题:

准备一个包含所有数据库查询的容器是干净的,但仅在视图开始迭代此容器(它是可迭代的)时从视图中获取数据,而不是在控制器中获取数据“?

附录

我传递给视图的容器是“一种”模型,我们称之为ExpensiveObjectProvider。当这个容器被传递到视图时,数据还没有从数据库中获取。

容器封装的对象可能很昂贵。我认为仍然在控制器中执行此操作的唯一原因是错误处理(如果数据库查询出错、连接问题等)。您认为从控制器中的数据库中预取前 1-2-3 个对象,然后将容器传递给视图(如果没有发生异常)并让视图消耗预取的数据,这是一个很好的权衡吗?并在迭代容器时获取新项目?

【问题讨论】:

    标签: model-view-controller design-decisions


    【解决方案1】:

    通常数据库代码不会进入视图,它将位于模型或模型所依赖的 DAO 中。视图中的逻辑将很难测试,如果数据库访问代码也在其中,则非常混乱。

    【讨论】:

    • 是的,我传递给视图的容器是一种模型。当这个容器被传递给视图时,数据还没有从数据库中获取。
    • 好的,我现在明白了。如果数据库代码被封装在模型中,那么当视图需要它时这样做是干净的。
    • 容器封装的对象可能很昂贵。我看到仍然在控制器中执行此操作的唯一原因是错误处理(如果数据库查询出错、连接问题等)。您认为从控制器中的数据库中预取前 1-2-3 个对象,然后将容器传递给视图(如果没有发生异常)并让视图消耗预取的数据,这是一个很好的权衡吗?并在迭代容器时获取新项目?
    • 这在很大程度上取决于上下文,但一个好的规则是尽可能以最简单(最优雅/设计良好)的方式进行操作,然后在证明存在问题时优化性能。跨度>
    【解决方案2】:

    视图不应执行任何此类逻辑。控制器告诉视图要显示的数据。控制器从模型中获取这些数据。

    【讨论】: