0

再次，我有一个关于 Kohana 以及我应该如何使用模型函数的问题。

我想将控制器功能的一部分移动到更合适的模型中，以便能够从其他控制器访问此功能。（从我目前所读的内容来看，我认为从不同的控制器调用控制器函数被认为是糟糕的架构）。我的问题是，根据几种情况（即模型参数），此控制器功能会在不同的数据库表中创建一个日志条目并向某些用户发送电子邮件。

如果主要功能位于模型中，我应该如何创建此日志条目并发送邮件？我应该从第一个模型中实例化第二个模型，调用 log 函数，然后按照我从控制器中所做的那样发送邮件吗？

提前致谢。

4

1 回答 1

0

不幸的是，这是一个没有 1 个正确答案的问题。很大程度上取决于您更喜欢如何实现 MVC 模式。

在其基础 MVC 使用：模型、视图和控制器

模型 这些类应该代表数据库中的实体

例子：

Model_User映射到用户表中的实体

$user = new Model_User;
$user->first_name = 'Joe';
$user->last_name  = 'Smith';
$user->save();

视图 这些文件存储演示数据/模板（通常/大部分是 html）

例子：

索引.tpl

<h1>HELLO, WORLD!</h1>
<h2><?=$some_variable_from_controller?></h2>

控制器 这些文件处理传入的请求并处理要注入视图的数据

例子：

Controller_Home处理对主页的请求

class Controller_Home extends Controller {

    public function action_index(){
       $view = View::factory('index');
       $view->render();
    }

}

现在您已经掌握了基础知识，是时候了解这种有限结构所引发的特定问题了。控制器变得有点肥胖和凌乱。这将我们引向库或面向服务的体系结构。

这些库允许我们将大量逻辑移动到一个可移植的服务层中，可以轻松地在所有控制器、模型和其他库中使用。他们还将我们的代码分解成更小更简洁的块，这些块实际上是有意义的。

例子：

在我的控制器中，我可以简单地创建一个Social_Login_Service并按如下方式使用它，而不是使用一堆通过 facebook 登录用户的逻辑。

Social_Login_Service::facebook($user_email);

现在，您只会在登录控制器中看到 1 条干净的线条，而不是一堆杂乱无章的逻辑，这些逻辑会堆积在您的控制器中，直到它融化您的大脑才能看到。

这是一个可能的方向（也是我更喜欢的方向）的一个非常基本的概述。

将您的网站分解成更小的组件非常有用，如果您使用的是 Kohana，我建议使用模块 ( http://kohanaframework.org/3.1/guide/kohana/modules ) 这样做，它们很棒。

我希望这个小片段有所帮助。

于 2015-01-27T07:48:01.863 回答