一般关于mvc ...应该控制器传递数据到视图或视图应该直接从模型中获取?

时间:2009-09-23 03:17:21

标签: php model-view-controller

我正在努力学习并完全理解mvc模式并同时学习php。我决定构建基本的mvc框架,我可以在以后的各个项目中使用它。在这里阅读了很多关于mvc和模型/视图/控制器之间的耦合的帖子我有点迷失。目前我的理解是在Web应用程序控制器中处理来自浏览器的即将发出的请求,并且如果需要,调用方法模型类告诉模型改变其状态。然后控制器实例化将负责显示接口的适当视图类。 这是我不明白的一点......

  1. 现在,控制器是否应该通过适当的模型对象进行查看,并且视图应该在需要时从模型中提取所有数据?

  2. 或者控制器应该从模型中获取数据并将其传递给视图,可能将其全部包装到单个包装器对象中,视图将从中访问并从中获取数据?

  3. 或者视图应该在需要时简单地实例化适当的模型并直接从模型对象中提取数据?

  4. 从我在这里读到的

    http://www.phpwact.org/pattern/model_view_controller

    我倾向于第3个选项,其中控制器没有传递任何东西来查看和查看它需要的实例化模型。这是因为:

    1. 视图和控制器应具有相同的模型访问权

    2. 控制器不应仅仅作为视图和模型之间的中介。

    3. 真的有一种正确的方法可以做到这一点,还是取决于项目?对于对OOP有深刻理解但对php相对较新且对mvc架构不太清楚的人,你会推荐什么方法。或者也许我应该选择对我来说似乎正确的东西并从我的错误中吸取教训(虽然想避免这个错误;)?

      现在,请让我知道,如果我的问题不明确将尝试更好地解释那么..我也读了很多关于stackoverflow的帖子和不同网站上的大量文章,但仍然会感谢帮助所以提前感谢所有的答案

8 个答案:

答案 0 :(得分:13)

就个人而言,我一直是#2的支持者。视图不应该关心模型。对于这个问题,该视图根本不应该有任何处理。它应该做它应该做的事情,格式化数据。

控制的基本流程应该是:控制器接收来自浏览器的请求。它处理请求,决定需要哪些数据,并从模型中检索它。然后它将数据传递到视图中,格式化数据并显示它。

作为扩展,用户输入在控制器内部进行处理,并在需要时保存到模型中,然后将反馈输入到视图等中。需要注意的关键点是处理在控制器内部进行。

答案 1 :(得分:5)

就个人而言,我一直是#3的支持者。视图不应该关心控制器。视图不应该对控制器有任何依赖性。它应该做它应该做的事情,展示模型的视图。

控制的基本流程应该是:控制器从浏览器接收请求。它会对模型进行相关的任何更新,然后选择一个视图。然后将控件传递给视图,该视图从模型中获取数据并进行渲染。

作为扩展,用户输入可以被视为模型的一部分,控制器和视图都可以从中读取。需要注意的关键点是Controller和View应该没有相互依赖。这就是为什么这个模式被称为MVC。

现在,就个人而言,我发现MVC有点太单调乏味,所以我通常会将Controller和View混为一谈。但那不是真正的MVC。

答案 2 :(得分:4)

Web MVC和桌面MVC是两种非常不同的野兽。

在Web MVC中,View中的链接调用Controller上的方法,该方法更新模型,然后重定向到适当的View,打开模型并显示它需要的内容。

在桌面MVC中,选项3是错误的,因为视图和模型都应该使用相同的引用。在网络上,别无选择。

选项编号2不是MVC。它是MVP,其中Presenter是一个中介。

控制器具有对模型的写访问权限;视图只具有读取权限。

答案 3 :(得分:3)

这是一个非常有趣的问题。 根据我的经验,php中的大多数实现都将模型变量分配给视图:

$this->view->my_property = $modelObj->property

这是常见做法。 这种情况的常见原因是,如果您发送对象,则可以调用从视图中修改对象的方法。

//in the controller file
$this->view->myObject = $modelObj;

//in the view file, you could call an object modifying method
$this->myObject->delete();

从视图中修改模型被认为是不好的做法。有些人认为他们不希望他们的设计师能够从视图中调用模型修改方法。

话虽如此。我同意通常的做法,并倾向于将整个对象分配给视图并从那里显示它。只是训练自己不要在那里做手术。

第三个选项是将整个对象分配给视图。但有些对象在从视图中调用时会禁用方法。

答案 4 :(得分:2)

我认为这只是关于什么是更好的“推送”“拉”模型的一般性争论。没有“绝对”最好的解决方案。

答案 5 :(得分:1)

我之前有一个非常相似的问题。我觉得有用的想法如下:

MVC
Model -- Data store, alerts Views of changes
View -- Displays model, provides hooks for user interaction
Controller -- Handles user input

您可以在非网络应用中更频繁地使用MVC,其中许多类同时互相交互。

在Web应用程序中,MVC表示MVT(模型 - 视图 - 模板)

Model -- Strictly a data store, typically an ORM solution
View -- Handles web requests, provides for user input/output
Template -- Actually displays content (HTML, Javascript, etc.)

因此,在Web应用程序中,演示文稿在模板中处理,应用程序背后的逻辑在视图(或视图调用的类)中处理,模型负责保存数据。

答案 6 :(得分:0)

我倾向于让控制器充当模型和视图之间的中介,但通常这只是将这三者连接在一起的单行代码。如果你的模型,视图和控制器被正确地解耦,那么你应该使用它们。

答案 7 :(得分:0)

今天这么多开发人员无法获得MVC的原因是因为MVC的缩写从第一天开始就被错误地说明了,当时它进入了软件开发,但这个概念在当时和今天都是正确的。由于我来自旧学校,让我为你解释一下;在创建对象时,首先要创建一个模型,以便客户可以查看它,一旦获得批准,您就可以完全控制对象的制作方式。这就是今天产品制造的方式。

在今天的Web应用程序开发中,这个术语应该是VCM。为什么!您查看Web浏览器上的内容,然后单击一个操作按钮,即所谓的Controller。控制器警告Model,这是产生结果的指令或逻辑(即您的脚本)。然后将结果发送回用户进行查看。在软件工程中,您可以将其称为CMV;因为在编译和安装应用程序之前,用户无法查看任何内容。所以我们需要一个控制设备(PC);作为模型的操作系统和查看结果的监视器。如果你能理解这些概念,MVC应该开始看起来更加开胃。我希望这个概念能帮助别人理解MVC。