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

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

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

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

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


kohana kohana-3 kohana-3.3
person Apollo13    schedule 15.06.2014    source источник
comment
Похоже, вам лучше создать класс библиотеки. Это будет просто обычный класс, созданный в каталоге классов/библиотек вашего приложения. В библиотеке ваши методы могут выполнять логику и вызывать модели и быть доступны с любого контроллера.   -  person chrisboustead    schedule 16.06.2014
comment
Это звучит интересно. Я попробую. Прав ли я, что в будущем я должен использовать библиотечные функции всякий раз, когда мне нужна реализация более чем в одном контроллере, и это связано не только с моделью?   -  person Apollo13    schedule 17.06.2014
comment
Дополнительную информацию можно найти в Интернете при поиске репозитория. Это убирает всю логику базы данных с ваших контроллеров, и вы можете повторно использовать методы на разных контроллерах.   -  person Moe    schedule 07.08.2014

Ответы (1)


arrow_upward
0
arrow_downward

Это вопрос, на который, к сожалению, нет 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), они великолепны.

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

person Eric Uldall    schedule 27.01.2015