Kohana 3.3 - как правильно перенести функцию контроллера в модель

Question

Снова у меня вопрос о Kohana и о том, как я должен использовать модельные функции.

Я хочу переместить части функции контроллера в более подходящую модель, чтобы иметь возможность доступа к этой функции из дополнительных контроллеров. (Из того, что я прочитал, я заключаю, что вызов функции контроллера из другого контроллера считается плохой архитектурой). Моя проблема заключается в том, что в зависимости от нескольких обстоятельств (то есть параметров модели) эта функция контроллера создает запись журнала в другой таблице базы данных и отправляет электронное письмо некоторым пользователям.

Как я должен создать эту запись в журнале и отправлять письма, если основные функции находятся внутри модели? Должен ли я создавать вторую модель из первой, вызывать функцию log, а затем отправлять письма точно так же, как я делал с моего контроллера?

Заранее спасибо.

Answer 1

На этот вопрос, к сожалению, нет 1 правильного ответа. Во многом это зависит от того, как вы предпочитаете реализовывать шаблон MVC.

В своей основе MVC использует: Модели, Представления и Контроллеры

МоделиЭти классы должны представлять сущности в вашей базе данных.

Пример:

Model_User сопоставляется с сущностью в вашей таблице Users

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

Представления Вэтих файлах хранятся данные / шаблоны презентаций (обычно html / в основном)

Пример:

index.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();
    }

}

Теперь, когда вы получили основы, пришло время понять конкретную проблему, которую продвигает эта ограниченная структура. Контроллеры становятся немного жирными и грязными. Это приводит нас к библиотекам или сервис-ориентированной архитектуре.

Эти библиотеки позволяют нам перемещать большие группы логики в переносимый сервисный уровень, который можно легко использовать на всех контроллерах, моделях и других библиотеках. Они также разбивают наш код на более мелкие и краткие куски, которые действительно имеют смысл.

Пример:

В моем контроллере вместо использования логики, которая регистрирует пользователя через Facebook, я могу просто создать Social_Login_Service и использовать его следующим образом.

Social_Login_Service::facebook($user_email);

Теперь вы просто увидите одну чистую строку в вашем контроллере входа в систему, а не целую кучу логики, которая будет накапливаться в вашем контроллере до тех пор, пока он не растопит ваш мозг.

Это очень простой обзор возможного направления (и тот, который я предпочитаю).

Очень полезно разбить ваши сайты на более мелкие компоненты, и если вы используете Kohana, я рекомендую делать это с модулями ( http://kohanaframework.org/3.1/guide/kohana/modules), они великолепны.

Я надеюсь, что этот маленький фрагмент помог.