Также странно видеть HTTP клиент без настройки timeout соединения. У автора какой-то свой опыт работы с сетью. Я бы смотрел на этот пакет лишь с целью ознакомиться.
А нет ли в недрах телеграмма (или где-то еще) чатика, куда можно задать вопросы по Cycle? Посмотрел на нее и возникло несколько «а почему так?».
Например, почему через Repository я всегда заново обращаюсь к БД и надо получать уже выбранные сущности через Heap? Или почему Repository зависит от Select?
Наверняка это сделано по какой-то причине и решает определенные проблемы. Вот бы были профильные чаты где помогли входящим в проект (тыкнули хотя-бы на страницу доки).
Все жду когда сделают поддержку штук типа \MyClass@myMethod.
По аналогии с \MyClass::class.
Очень поможет при рефакторинге и переходе в IDE из файлов роутинга.
т.е. сейчас я могу сделать rename у класса, и все упоминания \MyClass::class поменяются на \MyNewClass::class. Было бы круто уметь такое для методов класса, т.к. все еще в некоторых местах названия методов содержатся в строках (роутинг яркий пример).
Если вы хотите развиваться как разработчик, это упомянутая серия уроков вам обязательна к просмотру (более того, вы с первого раза не поймете все, придется возвращаться и пересматривать).
Если вы предприниматель и разработка идет от «денег нет, я сам смогу», то лучший выбор это Laravel/Lumen.
Он не так сложен, есть куча инфы и уроков. Также относительно много дешевых разработчиков на поддержку и развитие (порог входа ниже).
На избыточность функционала не обращайте внимание, загружаются только те файлы, которые нужны для работы конкретной страницы.
Тоже считаю что проблему изначальную не решили, а обошли.
В первую очередь нужно добиться стабильности тестов.
С другой стороны вы пошли в направлении стандартных рекомендаций пирамиды тестирования: написали больше тестов покрывающих функционал какого-то модуля, при этом замокав взаимодействие с другими модулями.
Но не стоит полностью отказываться от кросс-модульных тестов, их может быть мало — но самые критичные сценарии лучше покрыть. Тем более у вас это уже реализовано.
Когда я от разработчика слышу, что он не пользуется xdebug (или альтернативы), то у меня возникают сомнения на счет его компетенции.
Ощущения сравнимы с тем, когда видишь программиста печатающего двумя указательными пальцами.
Огромное спасибо за статью, очень актуально!
Возникло несколько вопросов:
— Почему не разделены образы для dev/prod (xdebug и composer не нужны)?
— Меня отчасти смущает то, что в gitlab-ci.yml дублируется сцераний создания образа (тот же composer install). Ведь, в принципе, у нас уже есть Dockerfile, который собирает образ и для него можно запустить тесты.
— Можете подробнее рассказать о запуске очередей, что в принципе для этого нужно, как вы решали проблемы (вижу скрипты в docker/app, это с ними связано)?
Все больше убеждаюсь, что вам просто нужно обратиться к литературе, статьям по фреймворкам, которые вы используете. В этом нет ничего страшного, наоборот, хорошо, что вы начали этим интересоваться и задавать вопросы. Но на большинство вопросов уже есть ответы.
Чтобы не быть голословным:
Сейчас просто нет еще согласия насчет есть ли этот сервисный слой, если есть — то каков он и т.д.
Вам в issue ответили, что фреймворк никак не ограничивает вас структурировать проект так, как вы хотите. И толстые контроллеры у вас получаются только потому, то вы так пишете код. И никаких согласий что «Laravel провоцирует писать толстые контроллеры» не заметил (можете тыкнуть в конкретный ответ если я пропустил).
Вы, кстати, сами обратили внимание на то, что вы сделали?
Вы взяли фреймворк, придумали новый паттерн и воплотили его в жизнь на этом же самом фреймворке! То есть он достаточно гибок, чтобы воплотить другой архитектурный паттерн. А теперь задумайтесь, не в этом ли благо? Каждый может реализовать логику так, как он хочет. Только теперь я вообще не понимаю ваших претензий к фреймворку.
Они провоцируют. С этим глаголом согласились разработчики Laravel.
Вам так господин Тейлор сказал? То, что в доке приведены самые простые примеры уже обсуждалось не раз. В доке городить сервисный слой оверхед, она решает другую задачу. А вот в проекте больше шести человеко-месяцев выделить бизнес логику в отдельный слой уже необходимость.
public function actionUserHello($userId)
{
$user = $this->userRepository->get($userId);
return $this->renderView('hello', ['name' => $user->getFullName()]);
}
И решение озвученных вами проблем:
Современные фреймворки имеют общие для всех недостатки в реализации MVC:
1. Узкая трактовка MVC-представления (View) только как «Представление с шаблоном в PHP файле» вместо «Представление с любым рендерером».
Как раз наоборот, сейчас все более распространяется json формат, и современные фреймворки дают инструменты вернуть ответ в любом формате (json, xml, csv и даже pdf!).
Узкая трактовка MVC-модели только как как «Модель домена Базы Данных» вместо «Любой компилятор данных для представления».
Как слова «модель домена» и «база данных» вообще могут стоять рядом? То, что некоторые люди олицетворяют модель с табличкой в БД это их проблемы.
Провоцируют использование так называемых «Толстых Контроллеров» содержащих одновременно все логики: бизнеса, представления и взаимодействия.
Современные фреймворки ни на что не провоцируют, если вы бизнес логику пишете в контроллере — это ваши проблемы. По хорошему они содержат только логику взаимодействия.
Прочитал вашу статью, понравилось. Зацепился за другие — также интересно. Но вот чекать ваш блог на новые статьи неудобно. Вы где то еще их публикуете? Или может подскажете инструменты чтобы следить за источниками типа вашего блога?
Тикеты в JIRA не удаляются с мержем ветки, поэтому можно найти историю за несколько лет назад, когда и разработчик то уже уволился. Бывает в ревью проверяю и полноту описания задачи в JIRA.
Вы видели драйвер Mysql, который содержит SQL запрос для выполнения? У вас драйвер для отправки SMS содержит текст сообщения, не странно ли?
А нет ли в недрах телеграмма (или где-то еще) чатика, куда можно задать вопросы по Cycle? Посмотрел на нее и возникло несколько «а почему так?».
Например, почему через Repository я всегда заново обращаюсь к БД и надо получать уже выбранные сущности через Heap? Или почему Repository зависит от Select?
Наверняка это сделано по какой-то причине и решает определенные проблемы. Вот бы были профильные чаты где помогли входящим в проект (тыкнули хотя-бы на страницу доки).
По аналогии с \MyClass::class.
Очень поможет при рефакторинге и переходе в IDE из файлов роутинга.
т.е. сейчас я могу сделать rename у класса, и все упоминания \MyClass::class поменяются на \MyNewClass::class. Было бы круто уметь такое для методов класса, т.к. все еще в некоторых местах названия методов содержатся в строках (роутинг яркий пример).
Если вы хотите развиваться как разработчик, это упомянутая серия уроков вам обязательна к просмотру (более того, вы с первого раза не поймете все, придется возвращаться и пересматривать).
Если вы предприниматель и разработка идет от «денег нет, я сам смогу», то лучший выбор это Laravel/Lumen.
Он не так сложен, есть куча инфы и уроков. Также относительно много дешевых разработчиков на поддержку и развитие (порог входа ниже).
На избыточность функционала не обращайте внимание, загружаются только те файлы, которые нужны для работы конкретной страницы.
В первую очередь нужно добиться стабильности тестов.
С другой стороны вы пошли в направлении стандартных рекомендаций пирамиды тестирования: написали больше тестов покрывающих функционал какого-то модуля, при этом замокав взаимодействие с другими модулями.
Но не стоит полностью отказываться от кросс-модульных тестов, их может быть мало — но самые критичные сценарии лучше покрыть. Тем более у вас это уже реализовано.
Обычно на серверах его и нету, а отлаживать на серверах такая себе компетенция.
Ощущения сравнимы с тем, когда видишь программиста печатающего двумя указательными пальцами.
Возникло несколько вопросов:
— Почему не разделены образы для dev/prod (xdebug и composer не нужны)?
— Меня отчасти смущает то, что в gitlab-ci.yml дублируется сцераний создания образа (тот же composer install). Ведь, в принципе, у нас уже есть Dockerfile, который собирает образ и для него можно запустить тесты.
— Можете подробнее рассказать о запуске очередей, что в принципе для этого нужно, как вы решали проблемы (вижу скрипты в docker/app, это с ними связано)?
Чтобы не быть голословным:
Смотреть раздел Domain Logic Patterns
Вы, кстати, сами обратили внимание на то, что вы сделали?
Вы взяли фреймворк, придумали новый паттерн и воплотили его в жизнь на этом же самом фреймворке! То есть он достаточно гибок, чтобы воплотить другой архитектурный паттерн. А теперь задумайтесь, не в этом ли благо? Каждый может реализовать логику так, как он хочет. Только теперь я вообще не понимаю ваших претензий к фреймворку.
Да ладно
Вам так господин Тейлор сказал? То, что в доке приведены самые простые примеры уже обсуждалось не раз. В доке городить сервисный слой оверхед, она решает другую задачу. А вот в проекте больше шести человеко-месяцев выделить бизнес логику в отдельный слой уже необходимость.
И решение озвученных вами проблем:
Как раз наоборот, сейчас все более распространяется json формат, и современные фреймворки дают инструменты вернуть ответ в любом формате (json, xml, csv и даже pdf!).
Как слова «модель домена» и «база данных» вообще могут стоять рядом? То, что некоторые люди олицетворяют модель с табличкой в БД это их проблемы.
Современные фреймворки ни на что не провоцируют, если вы бизнес логику пишете в контроллере — это ваши проблемы. По хорошему они содержат только логику взаимодействия.