Почему отправка писем осуществляется в моделе?

[pistol]

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

[ksetrin]

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

[ElisDN]

Теоретически всё можно поместить в контроллер, но это будет слишком разрознено и нетестируемо. И если тот же код понадобится и в другом контроллере, то придётся копипастить снова и снова.

Хороший контроллер должен лишь создать/найти модель, сервис или компонент, заполнить его GET или POST-параметрами и запустить публичный метод, вообще не интересуясь тем, что там творится внутри.

[rugabarbo]

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

В целом Yii2 заточен на то, чтобы модели были "толстыми", но этим не стоит ограничивать себя, если хочется сделать иначе (: Хорошая заметка про толстые контроллеры была у Макарова: http://rmcreative.ru/blog/post/tolstye- ... zh-uzhasny

[SiZE]

Теоретически всё можно поместить в контроллер, но это будет слишком разрознено и нетестируемо.

А если в модуль?

[kutsanov]

А мне всегда казалось, что наоборот Yii заточен под толстые контроллеры.
Особенно если учесть AR, когда в контроллере рисуются немыслимые цепочки вызовов, чтобы вывести простой список.
В том числе от этого отказался от AR, и работаю, можно сказать по старинке. Есть свой класс Core, от него наследуют все модели.
Любое обращение к базе \yii::$app->db->createCommand() и подобным.
Что от этого получаю.
1. Тонкий контроллер, ниже пример метода сохранения

Код: Выделить всё

    public function actionAdmSet()
    {
        $Adm = new Adm();
        $Adm->set_prop_from_arr($_REQUEST);
        $Adm->set();
        if (Core::hasError()===false) $ar['success_txt'] = 'Запись успешно сохранена';
        Core::encode_echo($ar);
    } 

2. Полный, единообразный и понятный, на мой взгляд контроль данных внутри модели

Код: Выделить всё

public function set()
    {
        $this->id = ($this->id > 0) ? $this->id : null;
        $this->role = ($this->role != '') ? $this->role : null;

        if ($this->email == '') {
            Core::error("Поле <strong>E-mail</strong> обязательно к заполнению", 'email');
        } else {
            $sql = 'Select count(*) from auth_adm where email=:email and (auth_id<>:id or :id is null)';
            $params = [];
            $params['email'] = $this->email;
            $params['id'] = $this->id;
            $cnt = \yii::$app->db->createCommand($sql, $params)->queryScalar();
            if ($cnt > 0) {
                Core::error('E-mail <strong>"'.$this->email.'"</strong> уже есть в базе', 'email');
            } else {
                $EmailValidator = new \yii\validators\EmailValidator;
                if (!$EmailValidator->validate($this->email)) {
                    Core::error('Некорректное поле <strong>"E-mail"</strong>', 'email');
                }
            }
        }

        if ($this->pw == '') {
            Core::error("Поле <strong>Пароль</strong> обязательно к заполнению", 'pw');
        }
        if ($this->name_f == '') {
            Core::error("Поле <strong>ФАМИЛИЯ</strong> обязательно к заполнению", 'name_f');
        }
        if ($this->name_i == '') {
            Core::error("Поле <strong>ИМЯ</strong> обязательно к заполнению", 'name_i');
        }

        if (Core::hasError() === true) return;

        $transaction = \yii::$app->db->getTransaction();
        if (!$transaction) $transaction = \Yii::$app->db->beginTransaction();

        try {

            if ($this->id === null) {
                $fld = [];
                $fld['t'] = 'adm';
                $fld['role'] = $this->role;
                \yii::$app->db->createCommand()->insert('auth',$fld)->execute();
                $this->id = \yii::$app->db->getLastInsertID('auth_id_seq');
                $fld = [];
                $fld['auth_id'] = $this->id;
                $fld['email'] = $this->email;
                $fld['pw'] = $this->pw;
                $fld['name_f'] = $this->name_f;
                $fld['name_i'] = $this->name_i;
                $fld['name_o'] = $this->name_o;
                \yii::$app->db->createCommand()->insert('auth_adm',$fld)->execute();
            }

            $fld = $params = [];
            $fld['pw'] = $this->pw;
            $fld['name_f'] = $this->name_f;
            $fld['name_i'] = $this->name_i;
            $fld['name_o'] = $this->name_o;

            $params['auth_id'] = $this->id;
            $where = 'auth_id=:auth_id';
            \yii::$app->db->createCommand()->update('auth_adm', $fld, $where, $params)->execute();


            // Записываем права
            $params = [];
            $params['auth_id'] = $this->id;
            $where = 'auth_id=:auth_id';
            \yii::$app->db->createCommand()->delete('auth_perm', $where, $params)->execute();

            foreach ((array)$this->perm as $perm) {
                $fld = [];
                $fld['auth_id'] = $this->id;
                $fld['perm'] = $perm;
                \yii::$app->db->createCommand()->insert('auth_perm',$fld)->execute();
            }


            if (\app\component\Core::hasError() === false) $transaction->commit();
            else $transaction->rollBack();

        } catch (Exception $e) {

            $transaction->rollBack();
        }

    } 

--
Кто то скажет, кода больше, много лишнего. Теже Рулесы в AR решают часть валидации.
просто практика показала, что та же валидация, обычно гораздо сложнее, чем описание ее в рулесах
Просто даже для примера попробуйте описать вариацию email, чтобы всегда выкидывалась только одна ошибка.
Не говорю уже о том, что, тоже самое сохранение обычно происходит по нескольким таблицам. AR очень запутано, на мой взгляд. Хотя если кто думает по другому, спорить не буду.

[rugabarbo]

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

Например, использовать повсеместно доменную модель - глупо. Использовать сервисный слой в сайте-визитке - глупо. Использовать толстые контроллеры, если у приложения будет много клиентов (API, web, CRM, admin) - глупо. Использовать жирные модели, если приложение будет Enterprise размера - глупо. Использовать Angular для статических html-страничек - глупо. Закладывать фундамент под небоскрёб, если строится 5-этажный дом - глупо (: И т.д.

Если вашего подхода хватает для конкретного приложения и оно удачно с ним живёт и поддерживается, то вероятно всё норм.

[zelenin]

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

отправка писем это не работа с данными. Это инфрастуктурная задача. Решаться должно в сервисном слое.

[zelenin]

В целом Yii2 заточен на то, чтобы модели были "толстыми"

А мне всегда казалось, что наоборот Yii заточен под толстые контроллеры.

как вообще можно что-то заточить под одно или другое, если функционал пишет конечный разработчик?

[zelenin]

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

Например, использовать повсеместно доменную модель - глупо. Использовать сервисный слой в сайте-визитке - глупо. Использовать толстые контроллеры, если у приложения будет много клиентов (API, web, CRM, admin) - глупо. Использовать жирные модели, если приложение будет Enterprise размера - глупо. Использовать Angular для статических html-страничек - глупо. Закладывать фундамент под небоскрёб, если строится 5-этажный дом - глупо (: И т.д.

Если вашего подхода хватает для конкретного приложения и оно удачно с ним живёт и поддерживается, то вероятно всё норм.

не глупо, а чрезмерно, излишне, избыточно.

[rugabarbo]

как вообще можно что-то заточить под одно или другое, если функционал пишет конечный разработчик?

Yii предлагает нам не Data Mapper, а ActiveRecord из коробки (нарушая при этом SOLID в угоду rapid development). Конечно, можно выкинуть все фичи ActiveRecord и использовать их как обычный Data Mapper, но в этом случае богатый функционал AR будет игнорирован. Именно поэтому я считаю, что Yii ориентирован всё же на толстые модели. Возможно, слово "заточен" тут подобрано не очень удачно (: Скажу иначе: "предрасполагает" вновь прибывших писать толстые модели и/или контроллеры.

[rugabarbo]

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

Например, использовать повсеместно доменную модель - глупо. Использовать сервисный слой в сайте-визитке - глупо. Использовать толстые контроллеры, если у приложения будет много клиентов (API, web, CRM, admin) - глупо. Использовать жирные модели, если приложение будет Enterprise размера - глупо. Использовать Angular для статических html-страничек - глупо. Закладывать фундамент под небоскрёб, если строится 5-этажный дом - глупо (: И т.д.

Если вашего подхода хватает для конкретного приложения и оно удачно с ним живёт и поддерживается, то вероятно всё норм.

не глупо, а чрезмерно, излишне, избыточно.

Чрезмерное и избыточное порождается отсутствием здравого смысла, а то есть глупостью

[zelenin]

как вообще можно что-то заточить под одно или другое, если функционал пишет конечный разработчик?

Yii предлагает нам не Data Mapper, а ActiveRecord из коробки (нарушая при этом SOLID в угоду rapid development). Конечно, можно выкинуть все фичи ActiveRecord и использовать их как обычный Data Mapper, но в этом случае богатый функционал AR будет игнорирован. Именно поэтому я считаю, что Yii ориентирован всё же на толстые модели. Возможно, слово "заточен" тут подобрано не очень удачно (: Скажу иначе: "предрасполагает" вновь прибывших писать толстые модели и/или контроллеры.

viewtopic.php?t=33304#p170539

я уже в той же ветке или в другой формулировал так: yii подталкивает к говнокоду - все примеры кода ужасны, solid не используется принципиально, модель используется как хелпер всего, связанного с данными и не только итд итп. Но ни в коем случае под это он не заточен. Но и к нормальной разработке не располагает.

[zelenin]

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

Например, использовать повсеместно доменную модель - глупо. Использовать сервисный слой в сайте-визитке - глупо. Использовать толстые контроллеры, если у приложения будет много клиентов (API, web, CRM, admin) - глупо. Использовать жирные модели, если приложение будет Enterprise размера - глупо. Использовать Angular для статических html-страничек - глупо. Закладывать фундамент под небоскрёб, если строится 5-этажный дом - глупо (: И т.д.

Если вашего подхода хватает для конкретного приложения и оно удачно с ним живёт и поддерживается, то вероятно всё норм.

не глупо, а чрезмерно, излишне, избыточно.

Чрезмерное и избыточное порождается отсутствием здравого смысла, а то есть глупостью

ни в коем случае. Глупостью это будет только, если ты решишь сделать краткосрочный простой проект под заказ (фриланс или офис) в парадигме ddd, заранее просрав сроки. Для себя или с избытком времени - делай ради бога. Никому от этого плохо не будет, а тебе +1 к карме и экспириенсу.

[rugabarbo]

viewtopic.php?t=33304#p170539

я уже в той же ветке или в другой формулировал так: yii подталкивает к говнокоду - все примеры кода ужасны, solid не используется принципиально, модель используется как хелпер всего, связанного с данными и не только итд итп. Но ни в коем случае под это он не заточен. Но и к нормальной разработке не располагает.

Да, согласен, я неудачно выразился про заточку.