Еще немного про сервисный слой в PHP

Переосмыслив свой пример из статьи, я понял, что действительно провел для себя невидимую грань между Operation и Service, которые на самом деле являются одним слоем. В конце статьи сделал небольшую пометку, касаемо этого вопроса. Спасибо за развернутые комментарии.

Еще немного про сервисный слой в PHP

Теперь понял) да, это действительно имеет смысл. Но тут также может возникнуть вопрос: «Должен ли контроллер знать и уметь создавать такую зависимость?».

Еще немного про сервисный слой в PHP

Если вы намекаете на match, то в силу текущих задач я все еще очень часто использую php ниже 8-й версии, так что пишу, как привык)

Еще немного про сервисный слой в PHP

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

Еще немного про сервисный слой в PHP

Спасибо за комментарий. Как я и описывал выше, цель статьи — показать преимущества создания слоя сервисов при разработке архитектуры веб приложений. Возврат с помощью response() имеет тут чисто показательный характер.

Вы рискуете получить лишние данные прямо в сервисный слой. Используйте метод "$requests->validated()"

Да, так действительно будет гораздо лучше. Ну или определить внутри request метод, который вернет сущность (для более удобной работы) вместо массива. Спасибо за замечание)

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

Если теперь посмотреть с другого бока, то можно заметить что:
— Бизнес со своей стороны выдумывает проблемы, которые в данный момент не нужно решать и которые не факт, что когда-нибудь возникнут.
— Пытается продумать продукт наперед во всех деталях, заранее усложняя его дальнейшее развитие. Тот самый звездолет, что вы описали. Из этого пункта также следует развал абсолютно любой архитектуры.

в других профессиях люди учат действительно сложные вещи и не ноют

Интересно узнать по каким критериям вы судите, что действительно сложно, а что нет? В каждом ремесле есть свои нюансы и сложности и всегда есть чему учиться. Даже в той же верстке. А еще интересно узнать, с чего вы взяли, что эти люди не ноют?

— делают ненужную оптимизацию не там где узкие места а потому что «ну это же не оптимально так писать
— страдают НИХ синдромом

с этим согласен

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

мне кажется, это больше удел джунов

Возможности Vue, о которых не следует забывать

Видимо я не совсем правильно выразился). Я имел ввиду использовать код выше в свойстве template:

Vue.component('heading-component', {
    props: [ 'level' ],
    template: `<component :is="'h' + level"></component>`
});

Возможности Vue, о которых не следует забывать

Если бы этот компонент был описан с помощью стандартного шаблона, то содержал бы в себе до 6 условий v-if, описывающих разные уровни заголовков:

<h1 v-if="level === 1">
 <slot></slot>
</h1>
<h2 v-if="level === 2">
 <slot></slot>
</h2>
<h3 v-if="level === 3">
 <slot></slot>
</h3>
<h4 v-if="level === 4">
 <slot></slot>
</h4>
<h5 v-if="level === 5">
 <slot></slot>
</h5>
<h6 v-if="level === 6">
 <slot></slot>
</h6>

Как насчет:

<component :is="'h' + level"></component>

Кстати, далее вы показали хороший пример использования динамических компонентов.

Стилизация Select-Option (почти) без JavaScript

Неплохо, но на мой взгляд все эти кастомные контролы без использования js ломаются о суровую реальность «закрытия по клику на body» )

Как определить потенциал возможного сотрудника еще на стадии резюме

Не в обиду рекрутерам, думаю среди них есть толковые ребята (которые чем-то занимаются), но на моем опыте был случай, когда рекрутер работал по такому принципу: из 100 вакансий не отбирал 10-20, а все 100 скидывал тех. лиду, чтобы отобрал тот)

Методология БЭМ на примере стикеров в opencart

Opencart по умолчанию построен на вложенных селекторах, как шаблон, так и админка.

И это самый маленький и тоненький из минусов OpenCart )

По теме: я бы вложил .sticker как элемент блока .stickers, все-таки, они как таковые без него не существуют (вам обязательно нужен контейнер с relative). И более точно дал бы название, например product-stickers, потому что считаю что просто stickers — слишком абстрактно)

Фриланс или офис? Ответ фрилансера

Видимо не совсем точно выразился) свобода выбора работы. Сужу субъективно, основываясь на своем опыте. На фрилансе я был птицей вольного полета, строя график как хочу и выбирая проекты, которые хочу. В офисе же, несмотря на открытую семейную атмосферу и минимум ограничений (конкретно у меня в компании) — хочешь не хочешь, а надо делать конкретные задачи. Обычно все подходит, но иногда эти моменты удручают (Легаси, рутина).

Фриланс или офис? Ответ фрилансера

Самый главный и жирный плюс в пользу фриланса — свобода выбора. Т.е. имея хорошую репутацию на рынке, хороших заказчиков можно смело говорить людям, что жизнь удалась)
Другое дело — прийти к такому состоянию. Тут не каждому дано: кто-то не вырастет как спец. выше определенного уровня, кто-то просто дошел до более-менее нормального в его понимании дохода и плывет по течению, а кто-то не достаточно самоорганизован и так далее.

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

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

В общем, дело сугубо индивидуальное. Сам я плюсую в сторону фриланса, хоть сам и офисный работник)

Об IT без галстуков: Повышения, удержание и текучка в компаниях из СНГ и USA

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

Для бизнеса такие лошадки конечно имеют ценность, но рано или поздно они выгорят (или впадут в депрессию), если будут все время молчать и просто выполнять работу.

Поймай меня, если сможешь. Версия менеджера

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

Статьи такого рода всегда привлекали моё внимание и эта серия не исключение. Директор и главный бухгалтер — ждем статьи от ваших лиц)