提高MVC使用率

我忙于使用Kohana MVC框架在PHP中构建MVC应用程序，它工作得很好。但是我想解决一些小问题。提高MVC使用率

很多逻辑在控制器和控制器本身的动作之间重复。我一直在想它，我认为定义一个包含这个共享逻辑的对象是明智的，所以它不会重复。

然后我听说了一些播客和Preventing mission creep in your Views, or, ignorance is bliss的视图模型。所以视图模型就是我一直在寻找的东西。

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

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

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

也许我完全错误的轨道，应该做的不同。你对此有何想法？

编辑：

大多数我说的是收集正确的信息，并把它传递给正确的观点的逻辑。

举例：

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

来源

2009-12-23 Ikke

重复的逻辑表明需要进行某些重构，您不会说出那些关键字是什么，所以我们无法确定您重构它的位置，但不要重复自己是一个有用的原则。所以原创的想法很好。我想知道从Controller到DB的直接交互（即缺少模型）是否是重复原因的一部分？

查看模型不止DTOs。它们包含（或指向）业务数据，并具有相关的解释逻辑。在你参考的“任务蠕变”文章中，你会看到这个想法。视图本身想知道是否显示链接。该决定基于各种业务数据。您可以通过一个简单的showLink（）方法将该逻辑放在一起。然后视图可以专注于演示，viewModel可以专注于解释。而且，同样重要的是，实际的业务数据本身不知道该演示文稿。

来源

2009-12-23 09:28:13 djna

添加了一个示例。 – Ikke 2009-12-23 10:10:48

对不起，我不明白添加和编辑之间的重复，听起来不像代码是完全一样的 – djna 2009-12-23 15:34:03

在前面的段落中关于控制器中的重复代码解决您的担忧......通过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->权威性任何函数内。同意保留biz逻辑的观点，这就是整个想法。

来源

2009-12-23 09:37:55

我已经有了这样的设置。我有一个扩展模板控制器的应用程序控制器。并且每个其他控制器扩展应用程序控制器这么多的共享逻辑已经集中在一个地方。 – Ikke 2009-12-23 09:52:58

提高MVC使用率

回答

相关问题