1

我正忙着使用 Kohana MVC 框架在 PHP 中构建一个 MVC 应用程序，它运行良好。但是我想解决一些小烦恼。

许多逻辑在控制器和控制器本身的动作中重复。我一直在考虑它，我认为定义一个包含这个共享逻辑的对象会很聪明，所以它不会重复。

然后我在一些播客中听说了视图模型，以及防止你的视图中的任务蔓延，或者，无知是幸福。所以视图模型是我一直在寻找的。

但现在问题来了，你在视图模型中放了什么。我的想法是让视图模型收集相应视图所需的所有信息。这样做的好处是每个控制器/动作只需将输入数据传递给视图模型，然后将其传递给视图。

这是一个聪明的主意吗？代表测试，将模型传递给视图模型是明智的，因此可以模拟它。但我并没有真正使用模型。相反，我让控制器通过 Doctrine ORM 访问数据库。将每个查询转换为单独的方法似乎有点尴尬，但也许我错过了一些东西。

从我听说过的视图模型来看，它们只是普通的 DTO。但是在动态弱类型语言中这样做有什么好处呢？

也许我完全走错了路，应该做不同的事情。您对此有何看法？

编辑：

我所说的大部分逻辑是收集正确的信息并将其传递给正确的视图。

一个例子：

我有一个客户控制器。它们有两个动作：添加和编辑。对于这两个动作，我使用相同的视图。在这两个动作中，为视图分配了相同的变量。在添加动作中，当表单无效时，输入变量会再次传递给视图。在编辑操作中，现有值被传递。这是一个很大的重复，我想解决。

4

2 回答 2

2

重复逻辑表明需要进行一些重构，你没有说那个 loic 是什么所以我们不能确定你重构到哪里，但是不要重复你自己是一个有用的原则。所以原创的想法是好的。我想知道您从控制器到数据库的直接交互（即缺少模型）是否是重复的部分原因？

视图模型不仅仅是 DTO。它们包含（或指向）业务数据，并且还具有相关的解释逻辑。在您引用的“任务蠕变”文章中，您看到了这个想法。View 本身想知道是否显示链接。该决定基于各种业务数据。您可以在一个简单的showLink()方法中整合该逻辑。然后视图可以专注于呈现，viewModel 可以专注于解释。而且，同样重要的是，实际的业务数据本身对演示文稿一无所知。

于 2009-12-23T09:28:13.203 回答
0

解决您在前面段落中对控制器中重复代码的担忧... 对于 Kohana，我通常将通用控制器代码放在基本控制器中，并从中继承我的所有控制器。

例如，在一个项目中，我使用 Template_Controller 的修改版本来引用每个页面都可用的 Auth 模块作为 $this->auth。

abstract class Template_Controller extends Controller {

    /* @var Auth_Core reference to authorization class */
    protected $auth;

    public function __construct()
    {
        parent::__construct();
        [snip]
        $this->auth = new Auth();
    }
[...]
}

现在我所有的控制器都是这样开始的：

class Help_Controller extends Template_Controller {

因此，所有控制器都可以在任何函数中访问 $this->auth。同意将商业逻辑排除在观点之外，这就是整个想法。

于 2009-12-23T09:37:55.817 回答