С какой целью разрабатывается фреймворк

Не относящиеся к фреймворку и программированию вопросы
Tommi
Сообщения: 90
Зарегистрирован: 2013.08.01, 13:44

Re: С какой целью разрабатывается фреймворк

Сообщение Tommi »

получил компактный понятный человекочитаемый код, очищенный от неинтересного технического мусора. Даже уборщица в любой строке разберётся
Насчет человекочитаемости(для непрограммиста) не ясно.
В чем практический смысл что один какой то метод получился таким понятным?
В методе немного поместится, все равно чтобы понять больше надо другое все смотреть, другие методы, а этого уже без программиста под рукой просто человек не сделает.

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

Жизнь постоянно сталкивает с другими yii программистами. Максимум что на собеседованиях спрашивают - это rbac, который считается сложным. Если так поднять планку до DDD, то не факт что найдутся практики.

Забавно как бы в реале пришлось в команде срабатываться например ElisDN и uEhlO4a. Когда все так прям с фанатизмом стоят на своих точках зрения и чужой код считают говнокодом. Кровопролитие?
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

Tommi писал(а): 2019.05.09, 15:50 В чем практический смысл что один какой то метод получился таким понятным?
В методе немного поместится, все равно чтобы понять больше надо другое все смотреть, другие методы, а этого уже без программиста под рукой просто человек не сделает.
В чём смысл написания понятного кода? Именно в том, чтобы он был понятен всем, а не только автору. Чтобы визуально проверять соответствие алгоритма заданию. Чтобы легче внедрять новых программистов в проект. Чтобы удобно было сочинять такие же понятные юнит-тесты. Одни плюсы.
Tommi писал(а): 2019.05.09, 15:50 Раньше комменты заставляли писать, они бы пояснили коллеге любой код, потом комменты стали немодными, и сейчас вернулись что имена нужно подбирать такие чтобы понятней другим было и скрывать технические моменты.
Не "комменты стали немодными", а "люди оказались редисками". Сначала придумали писать отдельные комменты. Думали, что будет круто. Но на практике оказалось, что люди не любит их сочинять и забывают за ними следить. Код переписывают, а комменты исправлять забывают. И устаревшие комменты для коллег становятся адом. В итоге плюнули на комментарии и решили просто понятными именами писать код, чтобы комментарии к нему не требовались. Логично.
Tommi писал(а): 2019.05.09, 15:50 Жизнь постоянно сталкивает с другими yii программистами. Максимум что на собеседованиях спрашивают - это rbac, который считается сложным. Если так поднять планку до DDD, то не факт что найдутся практики.
Это специфика Yii, что из-за лёгкости и наличия русскоязычной документации в него идут все новички, еле осилив PHP и ООП. И только потом, набираясь опыта и знаний не из мира Yii, некоторые развиваются дальше до других продвинутых вещей. Или не развиваются.
Tommi писал(а): 2019.05.09, 15:50 Забавно как бы в реале пришлось в команде срабатываться например ElisDN и uEhlO4a. Когда все так прям с фанатизмом стоят на своих точках зрения и чужой код считают говнокодом. Кровопролитие?
Легко решается построением непересекающихся команд под разные цели с выбором одного лидера для каждой команды. Как собственник проекта стратегически решит кто из нас ему нужен, так и будет.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение samdark »

Как тот, кто поработал в командах или группах команд из 50+ человек, подтверждаю, что слои и DDD — прежде всего способы не сойти с ума от сложности, поделить ответственность между рабочими группами, хоть как-то находить общий язык с представителями бизнеса. Это всё не от хорошей жизни. Если у вас просто, не усложняйте.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: С какой целью разрабатывается фреймворк

Сообщение anton_z »

samdark писал(а): 2019.05.12, 19:48 Как тот, кто поработал в командах или группах команд из 50+ человек, подтверждаю, что слои и DDD — прежде всего способы не сойти с ума от сложности, поделить ответственность между рабочими группами, хоть как-то находить общий язык с представителями бизнеса. Это всё не от хорошей жизни. Если у вас просто, не усложняйте.
О чем я и говорю, какие 3 человека.
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение BrusSENS »

Эх, зашёл, почитал и понял, что до сих пор почти все "меряются писюнами", мол мой велосипед круче.
samdark писал(а): 2019.05.12, 19:48 Это всё не от хорошей жизни.
В том то и дело, что просто так парадигму DDD не будут использовать, а тут изначально новичкам рассказывают, что DDD парадигма - это чуть ли не серебряная пуля (тут - это в соседнем разделе про архитектуру). DDD не панацея и нужно использовать данную парадигму с огромной осторожностью и понимая, что ты делаешь. Тот же солид можно нарушать, если понимать что делаешь и какая у этого цена. Без бошки хоть DDD, хоть процедурно пиши - один фиг будет спагетти.
samdark писал(а): 2019.05.12, 19:48 Если у вас просто, не усложняйте.
Вооооот, именно об этом я и говорю) Зачем усложнять там, где это не нужно =)

UPD:
Вот я не понимаю почему не объясняют всем начинающим, что например стоит использовать StandAlone Action'ы. Как по мне очень крутая практика, использую давно и ни чуть не жалею.

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

<?php
namespace modules\callme\backend\actions;

use Yii;
use modules\callme\backend\forms\ClaimEditForm;
use modules\callme\backend\services\ClaimEditService;
use modules\callme\common\entities\Claim;
use yii\base\Action;
use yii\web\Controller;
use yii\web\NotFoundHttpException;

/**
 * Class ClaimEditAction
 * @package modules\callme\backend\actions
 */
final class ClaimEditAction extends Action
{
    /**
     * @var ClaimEditService
     */
    private $service;

    /**
     * ClaimEditAction constructor.
     * @param string $id
     * @param Controller $controller
     * @param ClaimEditService $service
     * @param array $config
     */
    public function __construct(string $id, Controller $controller, ClaimEditService $service, array $config = [])
    {
        $this->service = $service;
        parent::__construct($id, $controller, $config);
    }

    /**
     * @param int $id
     * @return string
     * @throws NotFoundHttpException
     * @throws \yii\db\Exception
     */
    public function run(int $id)
    {
        $claim = $this->findClaim($id);
        $form = new ClaimEditForm($claim);

        if ($form->load(Yii::$app->request->post()) && $form->validate()) {
            $this->service->update($form, $claim);
        }

        return $this->controller->render('edit', [
            'model' => $form
        ]);
    }

    /**
     * @param int $id
     * @return Claim
     * @throws NotFoundHttpException
     */
    private function findClaim(int $id): Claim
    {
        if (!$claim = Claim::findOne($id)) {
            throw new NotFoundHttpException();
        }

        return $claim;
    }
}
Вот, не DDD, но чего непонятного? Всё вроде нормально читается без лишней сложности.

А это я к чему? К тому, что нужно некоторые моменты более низкого уровня объяснять, а не кидать бедного знакомящегося с Yii человека в сложные парадигмы.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

BrusSENS писал(а): 2019.05.27, 17:48 Вот я не понимаю почему не объясняют всем начинающим, что например стоит использовать StandAlone Action'ы. Как по мне очень крутая практика, использую давно и ни чуть не жалею.
А без них было бы вот так, если бы Params Converter и Argument Resolver завезли:

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

final class ClaimController extends Controller
{
    public function show(Claim $claim)
    {
        return $this->render('show', compact('claim'));
    }

    public function edit(Claim $claim, Request $request, ClaimEditService $service)
    {
        $form = new ClaimEditForm($claim);

        if ($form->load($request->post()) && $form->validate()) {
            $service->update($claim->id, $form);
        }

        return $this->render('edit', compact('claim', 'form'));
    }
}
как в Laravel и Symfony. Вот и весь контроллер без кучи мусора. Тоже используют и не жалеют. Так что здесь всё относительно.
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

ElisDN писал(а): 2019.05.28, 10:11 А без них было бы вот так, если бы Params Converter и Argument Resolver завезли:

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

final class ClaimController extends Controller
{
    public function show(Claim $claim)
    {
        return $this->render('show', compact('claim'));
    }

    public function edit(Claim $claim, Request $request, ClaimEditService $service)
    {
        $form = new ClaimEditForm($claim);

        if ($form->load($request->post()) && $form->validate()) {
            $service->update($claim->id, $form);
        }

        return $this->render('edit', compact('claim', 'form'));
    }
}
как в Laravel и Symfony. Вот и весь контроллер без кучи мусора. Тоже используют и не жалеют. Так что здесь всё относительно.
Мусор появится когда методов будет поболее 2-х.
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

chungachguk писал(а): 2019.05.28, 13:00 Мусор появится когда методов будет поболее 2-х.
Восьми методов достаточно?

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

class ClaimController extends Controller
{
    public function index(Request $request, ClaimFetcher $claims) {}
    public function create(Request $request, Create\Handler $handler) {}
    public function edit(Claim $claim, Request $request, Edit\Handler $handler) {}
    public function publish(Claim $claim, Publish\Handler $handler) {}
    public function reject(Claim $claim, Request $request, Reject\Handler $handler) {}
    public function close(Claim $claim, Close\Handler $handler) {}
    public function delete(Claim $claim, Remove\Handler $handler) {}
    public function show(Claim $claim) {}
}

class ClaimCommentController extends Controller
{
    public function create(Claim $claim, Request $request, Create\Handler $handler) {}
    public function edit(Claim $claim, Comment $comment, Edit\Handler $handler) {}
    public function delete(Claim $claim, Comment $comment, Remove\Handler $handler) {}
}
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

ElisDN писал(а): 2019.05.28, 13:13
chungachguk писал(а): 2019.05.28, 13:00 Мусор появится когда методов будет поболее 2-х.
Восьми методов достаточно?

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

class ClaimController extends Controller
{
    public function index(Request $request, ClaimFetcher $claims) {}
    public function create(Request $request, Create\Handler $handler) {}
    public function edit(Claim $claim, Request $request, Edit\Handler $handler) {}
    public function publish(Claim $claim, Publish\Handler $handler) {}
    public function reject(Claim $claim, Request $request, Reject\Handler $handler) {}
    public function close(Claim $claim, Close\Handler $handler) {}
    public function delete(Claim $claim, Remove\Handler $handler) {}
    public function show(Claim $claim) {}
}

class ClaimCommentController extends Controller
{
    public function create(Claim $claim, Request $request, Create\Handler $handler) {}
    public function edit(Claim $claim, Comment $comment, Edit\Handler $handler) {}
    public function delete(Claim $claim, Comment $comment, Remove\Handler $handler) {}
}
Вот. Уже потихоньку начинает мусор накапливаться. Это ещё реализации нет. А если методы отличные от обычного круда и зависимости в каждом специфические.
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

chungachguk писал(а): 2019.05.28, 13:27 Вот. Уже потихоньку начинает мусор накапливаться. Это ещё реализации нет.
Если в реализации намусорить, то да, проблемы ТТУК при любом подходе будут.
А так ни загаженного конструктора, ни лишних приватных методов не вижу.
chungachguk писал(а): 2019.05.28, 13:27 А если методы отличные от обычного круда и зависимости в каждом специфические.
А тогда чем гора отдельных экшенов со своими специфическими зависимостями:

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

class ClaimShowAction extends Action
{
    public function run(int $id) {}
    private function findClaim(int $id) {}
}

class ClaimEditAction extends Action
{
    public function __construct(LoggerInterface $logger, Edit\Handler $handler, TokenChecker $checker) {}
    public function run(int $id) {}
    private function findClaim(int $id) {}
}
будет удобнее обычных экшенов с теми же специфическими зависимостями:

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

class ClaimController extends Controller
{
    public function __construct(LoggerInterface $logger) {}

    public function show(Claim $claim) {}
    public function edit(Claim $claim, Request $request, Edit\Handler $handler, TokenChecker $checker) {}
}
в этом конкретном случае "обычных" не-PSR-15 фреймворков?
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

ElisDN писал(а): 2019.05.28, 14:48 А тогда чем гора отдельных экшенов со своими специфическими зависимостями:

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

class ClaimShowAction extends Action
{
    public function run(int $id) {}
    private function findClaim(int $id) {}
}

class ClaimEditAction extends Action
{
    public function __construct(LoggerInterface $logger, Edit\Handler $handler, TokenChecker $checker) {}
    public function run(int $id) {}
    private function findClaim(int $id) {}
}
будет удобнее обычных экшенов с теми же специфическими зависимостями:

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

class ClaimController extends Controller
{
    public function __construct(LoggerInterface $logger) {}

    public function show(Claim $claim) {}
    public function edit(Claim $claim, Request $request, Edit\Handler $handler, TokenChecker $checker) {}
}
в этом конкретном случае "обычных" не-PSR-15 фреймворков?
Как минимум тем, что мусор накапливается в одном файле и в случае чего можно с большей долей уверенности считать, что любые изменения коснуться только одного конкретного action. Под мусором я подразумеваю наличие подобных методов

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

private function findClaim(int $id) {}
, которые могут меняться от метода к методу. Также набор параметров подобных методов

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

public function edit(Claim $claim, Request $request, Edit\Handler $handler, TokenChecker $checker) {}
может разрастаться и ни коим образом не относиться к остальным похожим методам. И лучше бы их вынести в конструктор, для последующего расширения класса action с похожей функциональностью.
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

Касаемо Yii, удобно в контроллере реализовать один только метод actions и сразу наглядно видеть какие именно роуты он обслуживает. До кучи один action с разными параметры повесить на разные роуты и всё в таком духе.
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение BrusSENS »

ElisDN писал(а): 2019.05.28, 14:48 А тогда чем гора отдельных экшенов со своими специфическими зависимостями:

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

class ClaimShowAction extends Action
{
    public function run(int $id) {}
    private function findClaim(int $id) {}
}

class ClaimEditAction extends Action
{
    public function __construct(LoggerInterface $logger, Edit\Handler $handler, TokenChecker $checker) {}
    public function run(int $id) {}
    private function findClaim(int $id) {}
}
Вы не ответили на главный вопрос - зачем усложнять там, где это не нужно? И вы реально считаете, что специфические зависимости не могут быть для действий создания и редактирования? Сервисы вполне себе самостоятельные, нужная бизнес логика, которая реально необходима всему сервисному слою находится в сущности, чего тут не так?
ElisDN писал(а): 2019.05.28, 14:48 будет удобнее обычных экшенов с теми же специфическими зависимостями:

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

class ClaimController extends Controller
{
    public function __construct(LoggerInterface $logger) {}

    public function show(Claim $claim) {}
    public function edit(Claim $claim, Request $request, Edit\Handler $handler, TokenChecker $checker) {}
}
в этом конкретном случае "обычных" не-PSR-15 фреймворков?
Эм... Простите... А с какого такого перепугу логгер течёт в контроллер? Логгер - прикладная штуковина, а она у Вас в контроллер течёт. При отключении что делать будете? DummyLogger создавать?) Или у Вас использование логгера на продакшне бесплатно по процессору? Что будете делать в случае, если отключить нужно логгирование в критической ситуации?
И еще не понятно, почему действие контроллера знает о прикладных штуках, вроде TokenChecker? Разве это не часть уже сервисного слоя должна знать это? А получается что низкоуровневая штуковина (коей я контроллер в контексте известных мне фреймворков и считаю, ибо тут роль контроллера принял-передал на обработку-отправил прислвный результат) знает о других низкоуровневых штуковинах. Забавно.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

chungachguk писал(а): 2019.05.28, 15:48 Как минимум тем, что мусор накапливается в одном файле и в случае чего можно с большей долей уверенности считать, что любые изменения коснуться только одного конкретного action. Под мусором я подразумеваю наличие подобных методов findClaim, которые могут меняться от метода к методу.
Про то и говорю, что случае наличия более удобных инструментов мусорный метод findClaim не нужен. Если же экшену вдруг понадобится куча других приватных методов, то это чаще показывает проблемы декомпозиции. И от философии легализации "мусор накапливается в одном файле" неплохо было идти к "мусор не накапливается нигде".
chungachguk писал(а): 2019.05.28, 15:48 Также набор параметров подобных методов edit(...) может разрастаться и ни коим образом не относиться к остальным похожим методам.
Это всё равно, что сказать:
Также набор параметров конструктора EditAction(...) может разрастаться и ни коим образом не относиться к остальным похожим экшенам.
Что десять параметров будут у экшена в контроллере, что эти же десять параметров переместятся в конструктор класса экшена. Что будет раздутый метод, что будет такой же или более раздутый класс. Разницы никакой.
chungachguk писал(а): 2019.05.28, 15:48 И лучше бы их вынести в конструктор, для последующего расширения класса action с похожей функциональностью.
Добавление сложности расширением экшенов через конфигурацию и наследование - это чаще маскировка, чем разумный подход.
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

chungachguk писал(а): 2019.05.28, 15:51 Касаемо Yii, удобно в контроллере реализовать один только метод actions и сразу наглядно видеть какие именно роуты он обслуживает.
Это только касаемо Yii так удобно делать контроллер-роутер + пять классов экшенов, так как маршрутизация по умолчанию основана на контроллерах. В PSR-микрофреймворках вместо классов-контроллеров делать такие классы-экшены удобнее и логичнее, так как маршруты можно подвязывать независимо.
chungachguk писал(а): 2019.05.28, 15:51 До кучи один action с разными параметры повесить на разные роуты и всё в таком духе.
Только для повторного переиспользования одного экшена в Yii это имеет смысл. Но чаще лишь из-за того, что экшен по недосмотру перегружен кодом. Если б экшен был тонкий, то весь профит от его переподключения бы изчез.
Последний раз редактировалось ElisDN 2019.05.29, 15:46, всего редактировалось 2 раза.
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

BrusSENS писал(а): 2019.05.28, 23:44 Вы не ответили на главный вопрос - зачем усложнять там, где это не нужно? И вы реально считаете, что специфические зависимости не могут быть для действий создания и редактирования? Сервисы вполне себе самостоятельные, нужная бизнес логика, которая реально необходима всему сервисному слою находится в сущности, чего тут не так?
Эм... Простите... Я наоборот выступаю за упрощение. Что вместо ваших семи классов-экшенов с тремя методами в каждом можно сделать мой всего один класс-контроллер с семью методами-экшенами, небольшой автоматизацией очистив от мусора.
BrusSENS писал(а): 2019.05.28, 23:44 Эм... Простите... А с какого такого перепугу логгер течёт в контроллер? Логгер - прикладная штуковина, а она у Вас в контроллер течёт.
Не нравится низкоуровневый LoggerInterface::warning - оберните в высокоуровневый DomainErrorHandler::handle. Не нравится завязываться на зависимость в контроллере - оборачивайте хэндлеры логированием исключений в декораторах или в шине. А если вообще не логируете доменные ошибки параллельно с красивым выводом их в UI, то это ваше дело.
BrusSENS писал(а): 2019.05.28, 23:44 При отключении что делать будете? DummyLogger создавать?) Или у Вас использование логгера на продакшне бесплатно по процессору? Что будете делать в случае, если отключить нужно логгирование в критической ситуации?
Закомментирую лишние или все таргеты для Monolog в контейнере. Не поможет - потрачу минуту времени и запилю-таки DummyLogger.

У меня весь проект логирование использует, а не только контроллеры. Или у вас отключение логов жёстким выпилом через composer remove делается, чтобы все десятки вызовов LoggerInterface пообвалились?
BrusSENS писал(а): 2019.05.28, 23:44 И еще не понятно, почему действие контроллера знает о прикладных штуках, вроде TokenChecker? Разве это не часть уже сервисного слоя должна знать это?
Ну так конторллер и должен дёргать сервисы из прикладного уровня. Перешёл человек из письма по старой ссылке восстановления пароля с токеном, а я сразу в начале экшена через прикладной TokenChecker проверку токена дёрну и ему напишу "Токен истёк". Если всё нормально - выведу форму вбивания нового пароля.
BrusSENS писал(а): 2019.05.28, 23:44 А получается что низкоуровневая штуковина (коей я контроллер в контексте известных мне фреймворков и считаю, ибо тут роль контроллера принял-передал на обработку-отправил прислвный результат) знает о других низкоуровневых штуковинах. Забавно.
Контроллер фреймворка - это как раз вторая сверху по уровню штуковина после самого фреймворка. И он дёргает нижележащий прикладной слой, дёргающий модель. Так что с уровнями всё нормально.
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

ElisDN писал(а): 2019.05.29, 15:02
chungachguk писал(а): 2019.05.28, 15:51 Касаемо Yii, удобно в контроллере реализовать один только метод actions и сразу наглядно видеть какие именно роуты он обслуживает.
Это только касаемо Yii так удобно делать контроллер-роутер + пять классов экшенов, так как маршрутизация по умолчанию основана на контроллерах. В PSR-микрофреймворках вместо классов-контроллеров делать такие классы-экшены удобнее и логичнее, так как маршруты можно подвязывать независимо.
chungachguk писал(а): 2019.05.28, 15:51 До кучи один action с разными параметры повесить на разные роуты и всё в таком духе.
Только для повторного переиспользования одного экшена в Yii это имеет смысл. Но чаще лишь из-за того, что экшен по недосмотру перегружен кодом. Если б экшен был тонкий, то весь профит от его переподключения бы изчез.
Ну, т.е по сути мы приходим к тому, что всё таки лучше выделять action в отдельный класс, а не городить кучу методов в одном классе. Тем более, что такие выделенные классы можно с минимальными затратами перенести на PSR-фреймворк и не выискивать зависимость методов.
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение ElisDN »

chungachguk писал(а): 2019.05.29, 16:31 Ну, т.е по сути мы приходим к тому, что всё таки лучше выделять action в отдельный класс, а не городить кучу методов в одном классе. Тем более, что такие выделенные классы можно с минимальными затратами перенести на PSR-фреймворк и не выискивать зависимость методов.
Да, по сути - можно. Либо делать один класс-контроллер:

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

class TaskController extends AbstractController
{
    public function index(Request $request, TaskFetcher $tasks) {}
    public function me(Request $request, TaskFetcher $tasks) {}
    public function own(Request $request, TaskFetcher $tasks) {}
    public function create(Request $request, Create\Handler $handler) {}
    public function edit(Task $task, Request $request, Edit\Handler $handler) {}
    public function childOf(Task $task, Request $request, ChildOf\Handler $handler) {}
    public function assign(Task $task, Request $request, Executor\Assign\Handler $handler) {}
    public function revoke(Task $task, Member $member, Executor\Revoke\Handler $handler) {}
    public function take(Task $task, Take\Handler $handler) {}
    public function takeAndStart(Task $task, TakeAndStart\Handler $handler) {}
    public function start(Task $task, Start\Handler $handler) {}
    public function move(Task $task, Request $request, Move\Handler $handler) {}
    public function plan(Task $task, Request $request, Plan\Set\Handler $handler) {}
    public function removePlan(Task $task, Plan\Remove\Handler $handler) {}
    public function status(Task $task, Request $request, Status\Handler $handler) {}
    public function progress(Task $task, Request $request, Progress\Handler $handler) {}
    public function type(Task $task, Request $request, Type\Handler $handler) {}
    public function archive(Task $task, Archive\Handler $handler) {}
    public function reinstate(Task $task, Reinstate\Handler $handler) {}
    public function delete(Task $task, Remove\Handler $handler) {}
    public function show(Task $task, Request $request) {}
}
если фреймворк предоставляет param converter и action injection, делающие экшены тоньше и не загромождающие конструктор...

Либо делать двадцать классов-экшенов если фреймворк так не умеет, если они толстые или если просто хочется их разнести для независимой работы как в микрофреймворках.

Это на любителя.
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: С какой целью разрабатывается фреймворк

Сообщение chungachguk »

ElisDN писал(а): 2019.05.29, 19:02
chungachguk писал(а): 2019.05.29, 16:31 Ну, т.е по сути мы приходим к тому, что всё таки лучше выделять action в отдельный класс, а не городить кучу методов в одном классе. Тем более, что такие выделенные классы можно с минимальными затратами перенести на PSR-фреймворк и не выискивать зависимость методов.
Да, по сути - можно. Либо делать один класс-контроллер:

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

class TaskController extends AbstractController
{
    public function index(Request $request, TaskFetcher $tasks) {}
    public function me(Request $request, TaskFetcher $tasks) {}
    public function own(Request $request, TaskFetcher $tasks) {}
    public function create(Request $request, Create\Handler $handler) {}
    public function edit(Task $task, Request $request, Edit\Handler $handler) {}
    public function childOf(Task $task, Request $request, ChildOf\Handler $handler) {}
    public function assign(Task $task, Request $request, Executor\Assign\Handler $handler) {}
    public function revoke(Task $task, Member $member, Executor\Revoke\Handler $handler) {}
    public function take(Task $task, Take\Handler $handler) {}
    public function takeAndStart(Task $task, TakeAndStart\Handler $handler) {}
    public function start(Task $task, Start\Handler $handler) {}
    public function move(Task $task, Request $request, Move\Handler $handler) {}
    public function plan(Task $task, Request $request, Plan\Set\Handler $handler) {}
    public function removePlan(Task $task, Plan\Remove\Handler $handler) {}
    public function status(Task $task, Request $request, Status\Handler $handler) {}
    public function progress(Task $task, Request $request, Progress\Handler $handler) {}
    public function type(Task $task, Request $request, Type\Handler $handler) {}
    public function archive(Task $task, Archive\Handler $handler) {}
    public function reinstate(Task $task, Reinstate\Handler $handler) {}
    public function delete(Task $task, Remove\Handler $handler) {}
    public function show(Task $task, Request $request) {}
}
если фреймворк предоставляет param converter и action injection, делающие экшены тоньше и не загромождающие конструктор...

Либо делать двадцать классов-экшенов если фреймворк так не умеет, если они толстые или если просто хочется их разнести для независимой работы как в микрофреймворках.

Это на любителя.
Не можно, а лучше. Это была изначальная тема дискуссии )) И дело не только во вкусе, а то что это больше похоже на Yii (речь шла именно о нём): писать код через конфигурациии классов (Yii::createObject).
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: С какой целью разрабатывается фреймворк

Сообщение BrusSENS »

ElisDN писал(а): 2019.05.29, 15:45 Эм... Простите... Я наоборот выступаю за упрощение. Что вместо ваших семи классов-экшенов с тремя методами в каждом можно сделать мой всего один класс-контроллер с семью методами-экшенами, небольшой автоматизацией очистив от мусора.
Меньше классов не означает, что это хорошо. "Жирный" экшен и "тонкий" контроллер будет всё таки лучше, чем "Жирный" контроллер, уж по крайней мере в плане гибкости и самостоятельности.
ElisDN писал(а): 2019.05.29, 15:45 Не нравится низкоуровневый LoggerInterface::warning - оберните в высокоуровневый DomainErrorHandler::handle. Не нравится завязываться на зависимость в контроллере - оборачивайте хэндлеры логированием исключений в декораторах или в шине. А если вообще не логируете доменные ошибки параллельно с красивым выводом их в UI, то это ваше дело.
Я же говорю, логгер - это прикладная штука и высокоуровневой она быть не может. Он только и делает, что принятую строку пишет куда-то. Если он этого не делает, но его объект существует, то тут мы просто тратим ресурсы в пустую. + можно написать свой обработчик исключений и варнингов, для продакшна вполне хватит. И приложение об этом логгере не знает, как и должно. И при чём тут UI что-то не понял. Зачем логи в UI выводить?
ElisDN писал(а): 2019.05.29, 15:45 Закомментирую лишние или все таргеты для Monolog в контейнере. Не поможет - потрачу минуту времени и запилю-таки DummyLogger.
Ну вот, говорим про то, что бы всё автоматически было, а в итоге руками выпиливаем хардкод зависимости, за что и ругали Yii)
ElisDN писал(а): 2019.05.29, 15:45 У меня весь проект логирование использует, а не только контроллеры. Или у вас отключение логов жёстким выпилом через composer remove делается, чтобы все десятки вызовов LoggerInterface пообвалились?
Повторюсь ещё раз о том, что можно собственный обработчик исключений сделать, это дело нескольких минут. И да, через композер такой обработчик подключу в проект и при необходимости смогу полностью выпилить. Создатели PHP дали нам возможность работы с исключениями (и далеко неплохую кстати), а у нас пользуются ей для реализации валидаторов в каноничном DDD. Смех да и только. Только и читаешь, как в PHP придумали как мылом гвозди забивать. Не хочу никого обидеть, но стали уже просто с ума сходит с принципами каноничной архитектуры. А в итоге видал, как один клоун делал классы для того, что бы текстовые константы имели тип. Он об SPL даже не знает, зато о DDD пишет (если найду ссыль на эту статью, обязательно скину).
ElisDN писал(а): 2019.05.29, 15:45 Ну так конторллер и должен дёргать сервисы из прикладного уровня. Перешёл человек из письма по старой ссылке восстановления пароля с токеном, а я сразу в начале экшена через прикладной TokenChecker проверку токена дёрну и ему напишу "Токен истёк". Если всё нормально - выведу форму вбивания нового пароля.
В случае Yii, данный прикладной сервис относится к действию, нежели к контроллеру. Зачем тащить в контроллер зависимость, которая нужна для 1 действия из всех? Для этого, в реалиях Yii2 подходят прекрасно StandAlone экшены. Свой конструктор, никакого лишего кода логики из других действий, свои методы, которые доступны только для данного действия.
Тут конечно стоит добавить, что я очень надеюсь, что в Yii когда-нибудь выпилят экшены и контроллер будет обрабатывать реально одну команду, а не будет служить своего рода списком действий.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Ответить