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 回答