Страница 5 из 6
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.09, 15:50
Tommi
получил компактный понятный человекочитаемый код, очищенный от неинтересного технического мусора. Даже уборщица в любой строке разберётся
Насчет человекочитаемости(для непрограммиста) не ясно.
В чем практический смысл что один какой то метод получился таким понятным?
В методе немного поместится, все равно чтобы понять больше надо другое все смотреть, другие методы, а этого уже без программиста под рукой просто человек не сделает.
Раньше комменты заставляли писать, они бы пояснили коллеге любой код, потом комменты стали немодными, и сейчас вернулись что имена нужно подбирать такие чтобы понятней другим было и скрывать технические моменты.
Жизнь постоянно сталкивает с другими yii программистами. Максимум что на собеседованиях спрашивают - это rbac, который считается сложным. Если так поднять планку до DDD, то не факт что найдутся практики.
Забавно как бы в реале пришлось в команде срабатываться например ElisDN и uEhlO4a. Когда все так прям с фанатизмом стоят на своих точках зрения и чужой код считают говнокодом. Кровопролитие?
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.09, 21:47
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. Когда все так прям с фанатизмом стоят на своих точках зрения и чужой код считают говнокодом. Кровопролитие?
Легко решается построением непересекающихся команд под разные цели с выбором одного лидера для каждой команды. Как собственник проекта стратегически решит кто из нас ему нужен, так и будет.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.12, 19:48
samdark
Как тот, кто поработал в командах или группах команд из 50+ человек, подтверждаю, что слои и DDD — прежде всего способы не сойти с ума от сложности, поделить ответственность между рабочими группами, хоть как-то находить общий язык с представителями бизнеса. Это всё не от хорошей жизни. Если у вас просто, не усложняйте.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.13, 01:50
anton_z
samdark писал(а): ↑2019.05.12, 19:48
Как тот, кто поработал в командах или группах команд из 50+ человек, подтверждаю, что слои и DDD — прежде всего способы не сойти с ума от сложности, поделить ответственность между рабочими группами, хоть как-то находить общий язык с представителями бизнеса. Это всё не от хорошей жизни. Если у вас просто, не усложняйте.
О чем я и говорю, какие 3 человека.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.27, 17:48
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 человека в сложные парадигмы.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 10:11
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. Вот и весь контроллер без кучи мусора. Тоже используют и не жалеют. Так что здесь всё относительно.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 13:00
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-х.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 13:13
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) {}
}
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 13:27
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) {}
}
Вот. Уже потихоньку начинает мусор накапливаться. Это ещё реализации нет. А если методы отличные от обычного круда и зависимости в каждом специфические.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 14:48
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 фреймворков?
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 15:48
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. Под мусором я подразумеваю наличие подобных методов
, которые могут меняться от метода к методу. Также набор параметров подобных методов
Код: Выделить всё
public function edit(Claim $claim, Request $request, Edit\Handler $handler, TokenChecker $checker) {}
может разрастаться и ни коим образом не относиться к остальным похожим методам. И лучше бы их вынести в конструктор, для последующего расширения класса action с похожей функциональностью.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 15:51
chungachguk
Касаемо Yii, удобно в контроллере реализовать один только метод actions и сразу наглядно видеть какие именно роуты он обслуживает. До кучи один action с разными параметры повесить на разные роуты и всё в таком духе.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.28, 23:44
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? Разве это не часть уже сервисного слоя должна знать это? А получается что низкоуровневая штуковина (коей я контроллер в контексте известных мне фреймворков и считаю, ибо тут роль контроллера принял-передал на обработку-отправил прислвный результат) знает о других низкоуровневых штуковинах. Забавно.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 14:50
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 с похожей функциональностью.
Добавление сложности расширением экшенов через конфигурацию и наследование - это чаще маскировка, чем разумный подход.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 15:02
ElisDN
chungachguk писал(а): ↑2019.05.28, 15:51
Касаемо Yii, удобно в контроллере реализовать один только метод actions и сразу наглядно видеть какие именно роуты он обслуживает.
Это только касаемо Yii так удобно делать контроллер-роутер + пять классов экшенов, так как маршрутизация по умолчанию основана на контроллерах. В PSR-микрофреймворках вместо классов-контроллеров делать такие классы-экшены удобнее и логичнее, так как маршруты можно подвязывать независимо.
chungachguk писал(а): ↑2019.05.28, 15:51
До кучи один action с разными параметры повесить на разные роуты и всё в таком духе.
Только для повторного переиспользования одного экшена в Yii это имеет смысл. Но чаще лишь из-за того, что экшен по недосмотру перегружен кодом. Если б экшен был тонкий, то весь профит от его переподключения бы изчез.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 15:45
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
А получается что низкоуровневая штуковина (коей я контроллер в контексте известных мне фреймворков и считаю, ибо тут роль контроллера принял-передал на обработку-отправил прислвный результат) знает о других низкоуровневых штуковинах. Забавно.
Контроллер фреймворка - это как раз вторая сверху по уровню штуковина после самого фреймворка. И он дёргает нижележащий прикладной слой, дёргающий модель. Так что с уровнями всё нормально.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 16:31
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-фреймворк и не выискивать зависимость методов.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 19:02
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, делающие экшены тоньше и не загромождающие конструктор...
Либо делать двадцать классов-экшенов если фреймворк так не умеет, если они толстые или если просто хочется их разнести для независимой работы как в микрофреймворках.
Это на любителя.
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.29, 19:53
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).
Re: С какой целью разрабатывается фреймворк
Добавлено: 2019.05.30, 02:03
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 когда-нибудь выпилят экшены и контроллер будет обрабатывать реально одну команду, а не будет служить своего рода списком действий.