代码之家 › 专栏 › 技术社区 › alex

我在科哈纳3号“做错了”吗?

kohana-3 kohana php

0

alex · 技术社区 · 15 年前

当我有一个控制器,例如文章,我经常有一个 action_view() 处理大部分代码。

有时,它可以变成80-100行长。

我的控制器通常处理所有这些:

绑定模板变量
设置会话(如适用)
发送电子邮件
正在验证表单

我可以看到我可以在控制器中创建另一个私有方法,这不一定是为了重用,而是为了分离关注点。

然而,在我看来,有可以通过路由调用的方法,以及只在内部调用的方法是很奇怪的。

还有一些事情对我说“我应该在模型中,而不是控制器中”。不过,我也不确定这是否正确。

最后,我有一个比较胖的控制器方法,看起来很程序化。

我真的应该在我的 action_* 方法,然后将我的其余代码分成更小的模块?

我有一个例子…这是典型的控制器,还是会话等应该在模型中?

public function action_pdf($type, $id) {

        // Get PDF file from db and send headers to it
        $id = (int) $id;

        $pdfFile = $this->model->getPdf($id, $type);

        if ($pdfFile) {
           $this->request->redirect($pdfFile);
        } else {
           $this->session->set('pdfMissing', true);
           $this->request->redirect(Route::get('properties')->uri());
        }

    }

所以,我的问题是,我做错了吗?

2 回复 | 直到 12 年前

1

3

hiddentao 15 年前

您的模型用于封装业务逻辑,通常用于将数据存储层从体系结构的其他部分(控制器、视图)中抽象出来。

这意味着,任何数据库访问(如sql查询)等都应该理想地包含在模型中。您的控制器将从您的模型(包括orm,它通过模型公开自己)获取数据,而不必自己直接访问数据库。

至于电子邮件的发送,我想这要视情况而定。例如,当用户注册时,我调用一个模型方法将其详细信息插入数据库。然后,此方法触发一封电子邮件发送给他们。通过这种方式,我使电子邮件发送成为注册业务逻辑的一个明确部分(在本例中,这就是我想要的),因此无论模型中谁调用注册方法,系统都不会忘记发送电子邮件。

在表单验证方面,我尝试在orm模型类中指定大多数验证规则。因此,无论谁操纵模型,模型总是对如何验证自己的数据有一些内在的理解。您会注意到orm模型对象已经提供了一种验证其数据的方法。模型本身不需要知道保持跟踪的任何额外验证/回调都可以在模型代码之外完成。

2

1

G-Wiz RameshVel 15 年前

IANPHPD(我不是PHP DEV),但是通用编程语言(Java/C)开发人员的观点可能会有所帮助。对我来说,mvc的一个好处是,当您拥有核心业务逻辑和基础架构时,需要向多个ui展示这些逻辑和基础架构,从而促进代码重用。例如,具有Web界面和桌面界面的订单管理系统。在这种情况下,核心逻辑就是模型。这三个接口都有自己的视图和控制器。在c中,将代码结构成核心逻辑位于一组从桌面ui项目和web应用程序项目引用的包/程序集中是很简单的。

我认为即使我很确定某个应用程序不需要另一个用户界面。当我试图决定是否应该在模型或控制器中加入某些内容时,我 问问自己,这个功能是否应该从另一个ui中重用 .

这是一种对php代码有点不自然的思考方式,因为php与web平台的联系非常紧密(据我所知)。不管怎样,这种思维方式仍然有效(分离关注点,不要重复自己的想法)仍然可以应用: php可以支持的第二个“ui”是web服务api . 如果一个特性应该对网站和web服务api都可用,那么它应该在模型中公开。

您可能感兴趣,也可能不感兴趣,但总的来说,这种思维方式与领域驱动的设计完美地结合在一起。

注意:虽然php支持的所有ui都是基于web的,但我仍然会谨慎地将web特定的关注点放在模型中(任何与浏览器会话、cookies、hit tracking等相关的内容),主要是因为这些关注点是以表示为中心的,而不是以业务为中心的,其次是因为at使得以后无论出于什么原因都很难将系统逐段移植到另一种语言/平台。