Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Question

[Дмитрий]

Планируем начинать новый проект и хотелось бы организовать структуру с учётом лучших практик.
Если кто-либо сможет предоставить реальный пример разделения приложения на слои (DDD) - буду искренне благодарен.

Предполагаю, что необходимо разделить приложение (app/) на Laravel-specific логику (контроллеры, мидлвари и прочее), Domain (интерфейсы, имплементации репозиториев):

взято отсюда

https://laravelinfo.com/struktura-prilozheniya-i-p...

А как Вы проектируете свои приложения?

Спасибо.

Answer 1

[Finsh]

Взять Symfony.
Только вот серьёзно, зачем делать из отвертки дрель, когда она уже есть. Вы думаете, что это будет быстрее? Вы думаете что это будет дешевле? Laravel прекрасен для своих, средних, задач, для "enterprise" берите Symfony.

Answer 2

[Вячеслав Плиско]

Главное правило счастливого энтерпрайза - не тащить методики и технологии в которых нет опыта. Если вы не работали на проектах с DDD, не делали своих пет проектов чтобы опробовать подход, то не надо тренироваться на больших проектах.
Я уже 10 проектов в мире симфони видел и с тремя работал, везде попытки сделать DDD заканчивались невероятной сложностью поддержки после которой даже битрикс не кажется ужасом. 4 дня и изменения в 32 файлах чтобы добавить в список сортировку и фильтрацию... Наверное, можно писать на DDD правильно и с быстрой разработкой и лёгкой поддержкой, но я ещё таких проектов ни сам не создавал, не работал с чужими, не видел в качестве примеров. Поддерживать 10 летний легаси стартанутый на php4 с глобальными переменными гораздо проще чем любую поделку ddd-шников.

Answer 3

[Kir ---]

Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.

И вот мы возвращаемся к Фреймворкам.
Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.

Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.

Larvel
Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
Раз нет ООП, то и нет всей теории и принципов связанных с ним.
А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.

Если взглянуть глубже, то открывается ещё больше ада:
ActiveRecord.
Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
Далеко за примерами ходить не нужно, уже треш.

Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
Повеситься. Сложность приложения зашкалит.

Symfony
Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".

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

Но, по правде говоря, слепить что-то годное возможность есть.
Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
И тут вы окажетесь правы — незачем.

Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
Спрашивается — и зачем? Просто потратили кучу времени.

Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.

Comments

[Евгений Педя]

Вообще-то Laravel построен на Symfony. Значит и Symfony не стоит использовать?
Статические вызовы для получения билдера в Eloquent это преступление?

[Kir ---]

fpinger: про sf у меня же тоже написано :) Но я, не вижу что-то схожести.
Может Larvel написан на основе sf 1?
Про Eloquent - см раздел ActiveRecord

[Евгений Педя]

Вообще-то работа с ActiveRecord в экшене возможна в простых приложениях, но не обязательна. Для сложной бизнес логики создаются слои поверх.
В Laravel используются отдельные компоненты Symfony, а не вся его помойка. Используемые компоненты обновляются до последних версий.

И ещё стоит сказать о магии. Вот поклонники Symfony - это часто поклонники своей магии. Они любят создавать для себя круглые дистрибутивы в вакууме. С чистого Symfony приложения не делаются, так ведь? Впрочем это возможно не к вам. Хотя я не знаю ваше отношение к магии.

Вопрос же целостности данных решать на уровне PHP не имеет смыла. Это должно решаться на уровне СУБД.

В PHP нужно решать вопрос быстрой разработки прототипа, вокруг развивающейся структуры БД.

[Kir ---]

fpinger:

Вообще-то работа с ActiveRecord в экшене возможна в простых приложениях

Читайте вопрос автора.

Для сложной бизнес логики создаются слои поверх.

Поверх чего? Поверх ActiveRecord? Зачем он тогда нужен во фреймворке, если есть DataMapping?

В Laravel используются отдельные компоненты Symfony

Значит Larvel не написан на основе Symfony. А написан с использованием компонентов Symfony. Но, суть Фреймворка именно в предложении концепции программисту как строить своё приложение.

Вопрос же целостности данных решать на уровне PHP не имеет смыла.

Вы в какой нормально форме данные в БД храните. В 5 или 6?
Я сомневаюсь, что хотя бы в 3.
Так что решать проблему целостности данных, вы будете частично в приложении. И так делают 99% разработчиков. И User::save без UserAddInfo::save вызвать очень просто. И таких ошибок воз и маленькая тележка. А в Enterprise их будет ещё больше, потому что людей над ним работает огого.

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

[Евгений Педя]

> Читайте вопрос автора.

Так и определитесь, возможно использование ActiveRecord в экшенах.

На самом деле это не обязательно в Laravel. То что так делают - не обязательно означает, что будет использовать топикстартер (хотя для этапа создания прототипа вполне нормально). Впрочем подобное позволяет вообще любой web фреймвок. Есть другая информация?

> Поверх чего? Поверх ActiveRecord? Зачем он тогда нужен во фреймворке, если есть DataMapping?

Бизнес - это больше чем заполнение полей данными. Если вы не заметили, то топикстартер упомянул DDD.

> Значит Larvel не написан на основе Symfony. А написан с использованием компонентов Symfony. Но, суть Фреймворка именно в предложении концепции программисту как строить своё приложение.

Именно. Отдельные компоненты из Symfony занимаются только тем, что хорошо умеют делать. Зачем писать велосипед. А вот фреймвок Laravel сверху их организует и создаёт флов разработки, который гораздо сложнее в чистом Symfony и совсем магичен в Yii.

Так что решать проблему целостности данных, вы будете частично в приложении. И так делают 99% разработчиков.

Но не интерпрайз. А теперь и биг дата, понимаешь.

Предварительная валидация данных - это не целостность данных. Хотя решается вполне элегантно в Laravel. И кастомные реквесты с валидаторами и мутаторы/акцессоры для модели.

Если БД построена не для интерпрайза, то хоть Java с его фреймвоками юзай. Всё одно толку не будет.

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

Это спорно.

[Михаил Шатилов]

Раз уж на то пошло, не могли бы вы прокомментировать magento 2?

[Влад Токарев]

Вы, наверное, много времени потратили на написание ответа, но только зачем. Зачем вы отвечаете автору на вопрос "Как правильно спроектировать приложение с уклоном в enterprise на XXX, но не на Laravel?". Уже есть несколько таких ответов про Symfony.

По вашей критике Laravel

Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах.

Это фасады - от них можно и стоит избавиться, это не работа со статическими методами объекта в прямом смысле.

Далеко за примерами{ссылка} ходить не нужно, уже треш.

К чему этот пример, что это вообще за сайт.

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.

Кто такое предлагает?

[index0h]

Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!

Вы пишите какую-то глупость. Строчный идентификатор для собранного конкретного сервиса - это вполне ок. Что вы предлагаете, по интерфейсу определять инстанс конечной реализации? Да, в АОП не так - но это вовсе не значит, что это прям лучше, или прям хуже, это по другому. Глупость же заключается в том, что вы пытаетесь оценивать систему на одной парадигме, оперируя терминологией и правилами другой.

[Kir ---]

index0h: Почитайте у Фаулера как нужно делать dic. И да, нужно получать реализацию по интерфейсу. И вообще один сквозной dic через все приложение - плохо.

По поводу парадигм. Какую предлагает symfony? )

[Kir ---]

Влад Токарев: Вы не правильно оценили мой ответ. Я не пишу как правильно спроектировать на ххх. Я написал развернуто, почему нельзя писать на ларвел

[index0h]

И вообще один сквозной dic через все приложение - плохо.

В чем проблема?)) Можно из отдельных контейнеров целую иерархию построить, если это нужно.

Почитайте у Фаулера как нужно делать dic.

Почитайте %FamousName% как нужно делать %Anything%. Давайте конкретней, что не так и почему это плохо))

И да, нужно получать реализацию по интерфейсу.

Т.е. для каждого инстанса нужно создавать отдельный интерфейс и двух идентичных сервисов поднимать нельзя. Замечательно, в этом случае задача например с пулом воркеров - не решабельна. Ну разве что для каждого конечного объекта вы создатите по отдельному интерфейсу. Звучит как булшит, не находите?

Какую предлагает symfony? )

Обычное SOA

[Влад Токарев]

Я написал развернуто, почему нельзя писать на ларвел

Kir ---: все ваши доводы в рамках разработки на Laravel решаемы, и топикстартера как раз интересует, как это сделать. Так что какой смысл было писать столько текста, имея очень поверхностное знание Laravel, в то время, когда был задан конкретный вопрос, на который вы не ответили.

[Kir ---]

fpinger:

Так и определитесь, возможно использование ActiveRecord в экшенах.

Автор спрашивает про enterprise. Зачем вы начинаете приводить аргументы про блоги?
ActiveRecord хорош только на маленьких приложениях и для новичков. Т.к. он очень прост для обучения. Но его поддержка при увеличении объёма кода растёт экспоненциально.

Бизнес - это больше чем заполнение полей данными. Если вы не заметили, то топикстартер упомянул DDD.

Вы вообще на что это пишите? Я вас спрашиваю, поверх чего создаются слои и для чего.

А вот фреймвок Laravel сверху их организует и создаёт флов разработки,

И в чём заключается этот "флоу"? Пока что я вижу статики и нет концепции как понижать сложность разработки.

Но не интерпрайз. А теперь и биг дата, понимаешь.

Я не понимаю что вы несёте. При чём тут big data? Это две разные области с разными требованиями к приложениям.

Предварительная валидация данных - это не целостность данных

Я не говорю про валидацию пользовательского ввода. Я говорю про проверку целостности данных с точки зрения бизнес-логики.

Если БД построена не для интерпрайза

Вы хоть раз принимали участие в большой разработке? Хотя бы 25+ программистов, разделённых по командам, каждый отвечает за свою часть приложения?

Просто, все ваши ответы исходят из написания приложения объёмом блога или форума. И нет представления, что такое целостность данных.

[Kir ---]

В чем проблема?))

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

Почитайте %FamousName% как нужно делать %Anything%. Давайте конкретней, что не так и почему это плохо))

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

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

Вы решили решать задачу пула воркеров через IoC контейнер? Вы в своём уме?

Обычное SOA

А теперь идите и почитайте что такое парадигма. SOA не парадигма. Она не задаёт правил организации кода.

[Kir ---]

Влад Токарев:

Это фасады - от них можно и стоит избавиться, это не работа со статическими методами объекта в прямом смысле.

От роутинга тоже можно избавиться?
От ActiveRecord (подключения к БД)?
От Events?

К чему этот пример, что это вообще за сайт.

Нашёл типичный пример контроллера на laravel. Если у вас есть другой — приведите.

Кто такое предлагает?

Как вы предлагаете прозрачно внедрить RBAC в приложении на laravel? Какой подход предлагают авторы Фреймворка?

[Kir ---]

Планируем начинать новый проект и хотелось бы организовать структуру с учётом лучших практик

все ваши доводы в рамках разработки на Laravel решаемы, и топикстартера как раз интересует, как это сделать.

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

[Kir ---]

Михаил Шатилов: посмотрел. Это ж, вроде, CMS, а не Фреймворк

[Влад Токарев]

От роутинга тоже можно избавиться?
От ActiveRecord (подключения к БД)?
От Events?

Kir ---: конечно от этого всего, и вообще от любой части можно избавиться, а можно использовать любую из этих частей как библиотеку в своем приложении, а не как фреймворк.

Нашёл типичный пример контроллера на laravel. Если у вас есть другой — приведите.

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

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

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

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

[Kir ---]

Влад Токарев:

конечно от этого всего,

Зачем тогда этот Фреймворк брать вообще?

контроллер максимально простой

Очень простой. Жаль, что логики нет никакой. Давайте что-то во флоу laravel, где есть хотя бы обработка формы и работа с БД. А то пустые контроллеры, вообще не показательны ни для одного Фреймворка.

zugo в своем ответе написал описал проблематику

Проблематика такого ответа в том, что вы не понимаете что такое в принципе Фреймворк(см выше)
И если всё выбросить из Фреймворка и использовать свои подходы, то это — не использование Фреймворка.

оффтопят, предлагая другие инструменты.

Я тут пишу лишь потому, что хочу молодые умы отвадить от использования плохих практик и заставить учить не Фреймворки, а парадигмы и концепции.
Проблема многих в том, что нет понимания что такое ООП и какие из принципов данной парадигмы
следствия следуют. Что такое SOLID.
По одному только принципу Open-Close написана целая книжка у Бертрана Мэйера. Где все это ещё увязывается с GRASP. Принцип подстановки Барбары Лисков, так вообще чистая математика.

Но люди читают про Фреймворки и используют понятия нравится/не нравится. А нужно смотреть на теорию.
Видишь, что основа Фреймворка в статиках — значит писали его любители. Ничего приличного не выйдет, если следовать принципам заложенным в данном решении.
И т.д. и т.п.

[Влад Токарев]

Зачем тогда этот Фреймворк брать вообще?

Kir ---: Я писал, что можно выкинуть любую часть, а не непременно нужно все выкинуть.

Давайте что-то во флоу laravel, где есть хотя бы обработка формы и работа с БД.

Конкретных примеров контроллера сходу не найду, но вот интересный вариант структуры приложения.

вы не понимаете что такое в принципе Фреймворк(см выше)
И если всё выбросить из Фреймворка

Еще раз, не предлагаю я ВСЕ выбросить, просто утверждаю, что некоторые вещи, особенно фасады, надо выбросить.
Проблема Laravel в рамках темы обсуждения в том, что в документации нет информации о том, где хранить логику, поэтому большинство начинают ее хранить в контроллерах (или вообще во view, т.к. используемый шаблонизатор blade позволяет делать php вставки кода).

Как вы предлагаете прозрачно внедрить RBAC в приложении на laravel? Какой подход предлагают авторы Фреймворка?

Не заметил ранее этого вопроса. Вы так ставите вопрос, что фреймворк должен все уметь. Авторы не предлагают никакого подхода в этом вопросе, и Laravel из коробки не имеет механизмов работы с правами, только простейшую авторизацию. Есть несколько сторонних библиотек для Laravel, которые решают этот вопрос, какую из них выбрать, каждый решает сам, просто не надо утверждать, что этот вопрос, как и любой другой нерешаем в рамках фреймворка.

[Kir ---]

Влад Токарев:

Еще раз, не предлагаю я ВСЕ выбросить, просто утверждаю, что некоторые вещи, особенно фасады, надо выбросить.

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

Проблема Laravel в рамках темы обсуждения в том, что в документации нет информации о том, где хранить логику,

Строго говоря, он предлагает это делать в контроллерах (https://laravel.com/docs/5.4/controllers)

Instead of defining all of your request handling logic as Closures in route files, you may wish to organize this behavior using Controller classes. Controllers can group related request handling logic into a single class. Controllers are stored in the app/Http/Controllers directory.

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

Я изначально написал, что в рамках данного Фреймворка аспектоориентированная задача, аля RBAC будет решена на основе private и protected методов класса. По другому это вы не сделаете.

Вчитайтесь в термин Фреймворк. Поймите его.

«Фреймворк» отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений. В то время как «фреймворк» диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию — «каркас», который нужно будет расширять и изменять, согласно указанным требованиям.

Другим ключевым отличием «фреймворка» от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во «фреймворке», пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий — «абстрактный» код фреймворка. При этом, «фреймворк» вызывает функции (классы) пользовательского кода

Как только вы выбрасываете часть Фреймворка, он, по сути, становится либо другим Фреймворком(самопалом) либо библиотекой.

[Евгений Педя]

Kir --- Я посмотрел приведённый вами пример. Контроллер в laravel не должен быть таким. Просто это пост начинающего ларовельщика. (Например он не умеет пользоваться именованными роутами и дествия над объектом выполняет через GET запросы.)

Весь метод контроллера можно разбить на уровне роутов (смешаны HTTP методы и действия).

Реквесты по каждому методу можно оформить свои с валидацией и передавать их сразу в метод контроллера.

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

По мне можно для любого инструмента не верные образцы использования и манипулировать ими. Другими словами: это не кот невкусный - это вы его готовить не можете.

Мой пример для задачи (накидал быстро)

file: routes/web.php

Route::get('products', [
    'as'   => 'products.show',
    'uses' => 'ProductController@products',
]);

Route::get('product/{product}/', [
    'as'   => 'product.show',
    'uses' => 'ProductController@product',
])->where('product', '[0-9]*');

Route::get('cart', [
    'as'   => 'cart.show',
    'uses' => 'CartController@show',
]);

Route::post('cart/{product}/{action}', [
    'as'   => 'cart.change',
    'uses' => 'CartController@change',
])->where([
    'product' => '[0-9]*',
    'action'  => 'append|reduce|clear',
]);

file: app/Http/Controllers/ProductController.php

<?php namespace App\Http\Controllers;

use App\Product;
use App\Cart;

class ProductController extends Controller
{
    const ITEMS_ON_PAGE = 10;

    public function products()
    {
        $products = Product::orderBy('price', 'desc')
            ->paginate(self::ITEMS_ON_PAGE);

        if (!count($products)) {
            // Как вариант, решать в отображении что сообщить, 
            // так как может не быть товаров вообще
            abort(404);
        }

        return view('product.list')
            ->with('products', $products)
            ->with('cart', Cart::summary());
    }

    public function product($productId)
    {
        $product = Product::find($productId);

        if (!$product) {
            abort(404);
        }

        return view('product.item')
            ->with('product', $product)
            ->with('cart', Cart::summary());
    }
}

file: app/Http/Controllers/CartController.php

<?php namespace App\Http\Controllers;

use App\Cart;
use Illuminate\Support\Facades\Log;

class CartController extends Controller
{
    public function show()
    {
        return view('cart.show')
            ->with('cart', Cart::all());
    }

    public function change($productId, $action)
    {
        try {
            // Изменение корзины внутреннее дело самой корзины
            Cart::change($productId, $action);
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), [$productId, $action]);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество.
        // А именно страница товара, списка товаров или корзина.
        return back();
    }
}

Осталось реализовать модели Cart и Product.
Кстати, с Product можно по методам и так из коробки работать.
И конечно можно изменить корзину методом полной очистки и ручного изменения количества. Много кода в laravel это не потребует. И намного прозрачней, чем с кодом Bitrix и Magento работать. Быстро получился прототип своей корзины без бремени универсальности.

[Евгений Педя]

Вы вообще на что это пишите? Я вас спрашиваю, поверх чего создаются слои и для чего.

Так как раз запросы по DDD и будут над ActiveRecord. А там ещё могут быть слои связанные с другими айтемами.

Специально внёс изменения в код выше, для понимания:

// ...
Route::post('cart', [
    'as'   => 'cart.change',
    'uses' => 'CartController@change',
]);

<?php namespace App\Http\Controllers;

// Для папки App\Http\Requests\ валидируемые запросы идут из коробки, 
// но требуют определения
// Например, реализуем проверку параметров сортировки
use App\Http\Requests\CartGet; 
// Здесь проверяем product_id и action
use App\Http\Requests\CartChange; 

// Наши реализации для DDD, которые работают с ActiveRecord
use App\Domain\Cart\GetRequest;
use App\Domain\Cart\ChangeRequest;

use Illuminate\Support\Facades\Log;

class CartController extends Controller
{
    public function show(CartGet $request)
    {
        $cart_request = new GetRequest($request);
        $cart = $cart_request->process();

        return view('cart.show')
            ->with('cart', $cart);
    }

    public function change(CartChange $request)
    {
        try {
            $cart_request = new ChangeRequest($request);
            $cart_request->process();
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), $request);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество
        return back();
    }
}

И валидация данных формы из коробки. Я добавил файл, но содержимое его уже работает.
Свои валидаторы по вкусу то же можно добавить.

<?php namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class CartChange extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'product_id' => 'required|exists:products,id', 
            'action'     => 'required|in:append|reduce|clear',
        ];
    }

    public function messages()
    {
        return [
            'product_id.required' => 'Не выбран товар.',
            'product_id.exists'   => 'Товар не доступен.',
            'action.required'     => 'Не выбрано действие над товаром',
            'action.in'           => 'Не верное действие над товаром',
        ];
    }
}

Вообщем я добавил обработку реквестов доступа к элементам домена. Улучшил тестируемость.

Если считаете валидацию волидацию отдельно недопустимой и готовы её перенести в реквесты домена (и так и нужно, если не вестись на фреймвок), то опять же, легко можно передать в метод контроллера вместо CartChange $request обычный Request $request.

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

Вы хоть раз принимали участие в большой разработке?

Вы правы, очень мало. Я фрилансер из далёкой провинции. Но даже мне понятно, что правка кода в PHP не должна влиять на целостность БД. Может повлиять на качество данных в какой-то мере. Но это не одно и то же.

[Влад Токарев]

Если выбросить все на статиках, от Фреймворка останется одно название.

Kir ---: Что за странная логика? Роутинг, работа с БД, да и все остальное останется. Обращение к элементам фреймворка может осуществляться следующими способами - 1) с помощью фасадов, которые просто передают в вызов экземпляра соответствующего класса нестатические методы, таких же, как у фасада были вызваны статически; 2) с помощью функций-хелперов; 3) с помощью Dependency Injection. Следует пользоваться последними двумя, хотя в документации используется 1-й вариант.

Фреймворк, это платформа, которая предлагает пути решения задач.
Если для решения задач, нужно выкинуть часть элементов Фреймворка, то он не предлагает решения для этой задачи.

Нет никаких готовых решений для построения сложных Enterprise приложений, фреймворк решает часть проблем, в частности роутинг, работа с БД, шаблонизатор из коробки, валидация данных, миддлвары, а использование части рекомендаций может создать проблемы.

Строго говоря, он предлагает это делать в контроллерах

Ок, предлагает, был не прав. Но не обязывает и делать этого не следует.

RBAC будет решена на основе private и protected методов класса. По другому это вы не сделаете.

Тут я не очень вас понимаю, какие private и protected методы, какого класса? Как надо по-другому? По-моему можно сделать как угодно, как раз Laravel позволяет делать все, что угодно, вклиниваясь в любую часть работы.

Как только вы выбрасываете часть Фреймворка, он, по сути, становится либо другим Фреймворком(самопалом) либо библиотекой.

Вообще очень странная логика. Фреймворк остается самим собой, просто не используется часть его функций, а то, что он не решает, решается сторонними библиотеками, написанными сторонними разработчиками специально для него, либо для общего использования.

В вашем же определении:

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

Т.е. фреймворк расширяется и изменяется согласно требованиям разрабатываемого приложения.

[Kir ---]

fpinger: супер! Серьёзно — супер.
А теперь можно конкретно поговорить про насущие проблемы больших проектов.

Вы уже из-за подхода Laravel начали во всю использовать статики: Card::change Log::error
Это абсолютно не рашсряемо. Если у вам нужно подменить логгер в зависимости от окружения. Задача, кстати, очень частая, когда подменяют именно логер.
Card::change - вы жестко завязались на метод change который что-то делает.

Проблема целостности логики приложения — тут не видно ни связи текущего пользователя с корзиной. Потенциальная уязвимость того, что вы можете привязать товар ни к той корзине. Если один экшен, это не так критично. А представьте, если таких мест десятки. Как пример амазон. Там различных способов работы с корзиной кучи.

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

Вы, скажете, что это не проблема Laravel. А я скажу, что именно его. Потому что он не предоставляет своей методики, как правильно получать экземпляры, кроме как через запрос в контроллере через статические методы подключения к БД.
Ну не подразумевает их методика другого способа проброса коннекта.
Далее. Как вы собираетесь прикручивать ко всему этому гибкие права. Например, у пользователя с ролью менеджера есть права только на чтение.

Теперь возвращаемся к коду. В CartChange много чего завязано на какие то ассоциативные массивы и куча публичных методов Я не понимаю как это работает. Это вообще процедурное программирование. Тут нет реализации каких то интерфейсов, для понимания, что можно передать, а чего нельзя. Это сплошное нарушение SOLID, так как CartChange нарушает принцип единой ответственности. Он предоставляет различные данные разной с разной природой.

Даже передавать разный request для каждого action попахивает. Меняем строчку в роутинге и вам приходит другой объект. Потенциальное место огрести кучу неявных ошибок.

[Kir ---]

Влад Токарев:

Роутинг, работа с БД, да и все остальное останется.

Ну как так то. Мы же договорились, что статики это плохо и использовать нельзя. И вы предлагаете их тут же и оставить %)

Нет никаких готовых решений для построения сложных Enterprise приложений

Есть Фреймворки, которые декомпозируют задачу разработки сложных модульных приложений на составные части. Так же знают о специфике веб-приложений и представляют абстракции для того, что бы нивелировать сложности веб-специфики (сделать прозрачным её).
Как я уже говорил это Pyramid.

Ок, предлагает, был не прав. Но не обязывает и делать этого не следует.

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

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

Я не вижу каким это образом он это позволяет. Приведите пример, как вы организуете передачу соединения с БД в экшен и сделаете проверку прав на то, что пользователь имеет право получать данные для определённого company_id (задача, когда пользователь является работником компании, и только по ней имеет право получать данные).
Я вижу только один путь, который представляет вам Laravel — это использовать статические методы внутри экшенов.

Фреймворк остается самим собой, просто не используется часть его функций

Т.е. фреймворк расширяется и изменяется согласно требованиям разрабатываемого приложения.

Ещё раз прочитайте определение Фреймворка вдумчиво. Фреймворк предоставляет методику написания приложения на нём и вызывает ваш код (который написали вы).
Если же вы отключаете часть функциональности Фреймворка, то для вас он уже не является таким строго по определению. Вы начинаете его использовать как библиотеку.
Соответственно, вы уже не используете методику, которая предоставляется данным решением.
С вероятностью 99.9% вы просто придумываете свою методику, которая представляет из себя вкусовщину основанную на вашем личном эмпирическом опыте, т.е. говнокод.
Соответственно, уже ничего путного не выйдет.

[Влад Токарев]

Kir ---:

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

С какого перепугу он мешает? Некоторыми рекомендациями пользуюсь, некоторыми нет. Теми, что пользуюсь - они мне помогают, те, что помешали бы не пользуюсь.

Ещё раз прочитайте определение Фреймворка вдумчиво. Фреймворк предоставляет методику написания приложения на нём и вызывает ваш код (который написали вы).

Да, именно так, даже если я что-то делаю не по документации, именно Laravel вызывает мой код.

пример, как вы организуете передачу соединения с БД в экшен и сделаете проверку прав на то, что пользователь имеет право получать данные для определённого company_id

Не очень понимаю насчет "организуете передачу соединения с БД в экшен", почему я сам должен в экшн передавать соединение с БД?
Если требуются какие-то проверки на доступ, то они делаются через миддлвары.
Если пользователь привязан к 1 компании, то задача решается так:

$company = auth()->user()->company()->where('id', request('company_id'))->firstOrFail();

Если пользователь не принадлежит к компании, то будет 404.

[Евгений Педя]

Kir ---:

Вы уже из-за подхода Laravel начали во всю использовать статики: Card::change Log::error

Давайте отделим мух от котлет. Один метод мой и он не обязательно должен быть статичным, но при простой реализации он сразу скрыл всю кухню поиска нужной корзины и её изменений. Это же указано в комментарии: Изменение корзины внутреннее дело самой корзины

Ниже я изменил реализацию с учётом ваших желаний. Простая реализация с привязкой к сессии. Кроме того добавил немного кода модели.

class CartController extends Controller
{
    //...
    public function change($productId, $action)
    {
        try {
            $session_id = session()->getId();

            $cart = Cart::bySession($session_id)
                ->firstOrCreate(['session' => $session_id]);

            $cart->change($productId, $action);
            
        } catch(\Exception $e) {
            // Здесь можно разрешить как не стандартные ситуации, так и стандартные.
            // Но у нас пока одно.
            Log::error('Cart change: ' . $e->getMessage(), [$productId, $action]);

            return back()
                ->with('message', 'Простите, дяденька, засранца.');
        }

        // Возвращаемся туда от куда добавился товар или изменилось его количество
        return back();
    }
}

namespace App;

use Illuminate\Database\Eloquent\Model;

use App\Cart\ActionException;

class Cart extends Model
{
    // ...
    public function scopeBySession($query, $sessionId)
    {
        return $query->where('session', '=', $sessionId);
    }

    public function change($productId, $action)
    {
        switch($action) {
            case 'append':
                $this->processAppend($productId);
                break;
            case 'reduce':
                $this->processReduce($productId);
                break;
            case 'clear':
                $this->processClear($productId);
                break;
            default:
                throw new ActionException($action, $this->session, $productId);
        }
    }

    private function processAppend($productId)
    {
        // ...
    }
    // ...
}

Это абсолютно не рашсряемо. Если у вам нужно подменить логгер в зависимости от окружения. Задача, кстати, очень частая, когда подменяют именно логер.

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

Card::change - вы жестко завязались на метод change который что-то делает.

Проблема целостности логики приложения — тут не видно ни связи текущего пользователя с корзиной. Потенциальная уязвимость того, что вы можете привязать товар ни к той корзине. Если один экшен, это не так критично. А представьте, если таких мест десятки. Как пример амазон. Там различных способов работы с корзиной кучи.

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

Все методы что-то делают. Кроме того, по названию видно именно что делает мой метод. Это для простого решения.
Впрочем, выше я привёл реализацию с учётом сессии. Никто вам не мешает создать фабрику, получающую ряд параметров, и возвращающую нужную корзину. Это не проблема фреймвока. В его контексте нет корзины. Другими словами подвожу итог, что вы ругаете фреймвок за то, за что он не отвечает.

Теперь закончим насчёт статики. Первый вызов статического метода типа where() и т.д. в контексте Eloquent позволяет вызвать квери билдер в контексте модели. Так реализован Eloquent. Не нравится? Используйте привычную вам реализацию. Можете обратится к Doctrine.

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

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

Ответил выше. Нет никакого обращения к БД в данном контексте. Только к построителю запроса для модели. К какой БД обращается модель можно указать в самой модели (если их несколько в приложении). Контроллер ничего не знает о БД. И не должен знать.

Далее. Как вы собираетесь прикручивать ко всему этому гибкие права. Например, у пользователя с ролью менеджера есть права только на чтение.

Можем использовать систему полиси самого ларавеля. Уж извините, но я не буду пересказывать вам документацию.
Можем взять любую другую реализацию. Их много.
И точек для внедрения хватает. Всё зависит от контекста бизнес задачи.

class CartChange extends FormRequest
{
    // НАПРИМЕР, ОДНА ИЗ ТОЧЕК ПРОВЕРКИ ПРАВ!!!
    public function authorize()
    {
        return true; // Если в данном контексте мы этим не замарачиваемся
    }

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

Если знаете laravel и посмотрите на строчку use App\Http\Requests\CartChange; в контроллере, то всё становится понятно. Это обработчик одного запроса, валидирующий данные запроса. А если посмотреть в код, то видим, пусть и магическую, но вполне читаемую реализацию на основе встроенных валидаторов. Можно писать свои.
Сам FormRequest от которого мы наследовали CartChange имеет свой интерфейс. Впрочем и его вы можете расширить, если вам нужно.

В контроллере я передаю объект CartChange в метод обрабатывающий запрос. Если валидация не прошла, то до метода контроллера и дела не дойдёт. По умолчанию будет редирект на url с которого был запрос и вернутся сообщения об ошибках (в случае с Ajax будет просто возврат ошибок в json).

И что теперь стоит опять отметить (вы и сами это признали), то что вы не знаете laravel, но упорно пытаетесь его облажать.

Это сплошное нарушение SOLID, так как CartChange нарушает принцип единой ответственности. Он предоставляет различные данные разной с разной природой.

Вы сами себе противоречите. CartChange - это единственное место проверки данных единственного запроса. Для каждого запроса вы можете создать свой класс. Природа же данных запроса всегда одна - это текст из HTTP.

Даже передавать разный request для каждого action попахивает. Меняем строчку в роутинге и вам приходит другой объект. Потенциальное место огрести кучу неявных ошибок.

Вы можете использовать CartChange для нескольких разных запросов.
И если вы не заметили, то роуты именованные. Меняйте всё, кроме имён параметров. Не используйте имена параметров в URL без нужды. Всё в руках разработчика.

<!-- Вариант с параметрами в URL -->
<form action={{ route('cart.change', ['action' => 'append', 'product' => $produt->id]) }} method="post">
    {{ csrf_field() }}
    <button type="submit">+</button>
</form>
<span>{{ $cart->productQuantity($produt->id) }}</span>
<form action={{ route('cart.change', ['action' => 'reduce', 'product' => $produt->id]) }} method="post">
    {{ csrf_field() }}
    <button type="submit">-</button>
</form>

<!-- Вариант с CartChange Параметры в форме  -->

<form action={{ route('cart.change') }} method="post">
    {{ csrf_field() }}
    <input type="hidden" name="action" value="append"> 
    <input type="hidden" name="product" value="{{ $produt->id }}"> 
    <button type="submit">+</button>
</form>
<span>{{ $cart->productQuantity($produt->id) }}</span>
<form action={{ route('cart.change']) }} method="post">
    {{ csrf_field() }}
    <input type="hidden" name="action" value="reduce"> 
    <input type="hidden" name="product" value="{{ $produt->id }}"> 
    <button type="submit">-</button>
</form>

Резюмирую. Laravel вполне годен для энтерпрайза, если "умеешь готовить". Но это "умеешь готовить" ещё более важно для Symfony. Решения на Laravel можно добиться быстрее. При этом все зависит, как и всегда, от разработчиков.

Бизнесу нужны быстрые решения. Для этого нужно искать золотую середину, а не быть снобом.

[Kir ---]

fpinger:

Ниже я изменил реализацию с учётом ваших желаний. Простая реализация с привязкой к сессии. Кроме того добавил немного кода модели.

$cart = Cart::bySession($session_id)
                ->firstOrCreate(['session' => $session_id]);

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

Бизнесу нужны быстрые решения. Для этого нужно искать золотую середину, а не быть снобом.

Вы делаете даже в элементарных примерах кучи допущений, которых в рамках ООП быть не должно. Даже простые примеру имеют ужасающую сложность приложений.
Что говорить, когда вы начнёте чуть сильнее увеличивать количество функционала. Это превратится в ад.

[Евгений Педя]

Kir ---:
Мне не понятно ваше отношение к статическим методам. Можете объяснить?
Других аргументов я с вашей стороны не увидел. Только не знание laravel и фантазии по этому поводу.

[Kir ---]

fpinger вот видите, вы не понимаете, что использование статиков в архитектуре приложение, это костыль.
Помимо того, что статик автоматически увеличивает сочленение, так в вашем случае он уменьшает связность, ибо возвращает не экземпляр класса от которого вызван.
Уменьшение связности, это штука, которой нужно опасаться как огня. Она на степень увеличивает сложность приложения.

Что бы не сойти с ума от сложности, разработчикам IDE приходится придумывать плагины для поддержки тех или иных Фреймворков. Чем более функциональный плагин нужен для IDE, тем дальше framework от ООП. Чем дальше от ООП, тем меньше теоретической основы за framework'ом.
Чем меньше теоретической основы, тем больше ошибок заложено в архитектуре.
Чем больше ошибок в архитектуре, тем менее гибкие и масштабируемые системы, с приемлемой сложностью можно писать.
Приемлемая сложность приложения, это сложность:
- средняя цикломатическая сложность приложения не превышает 15. А лучше не превышает 10
- не должно быть наследования более 3х уровней.
- не должно быть методов с более чем 6ю аргументами
- не должно быть методов с более чем 120 строк.
Вообще, критериев оценки сложностей навалом, но я привел наиболее важные и базовые.
А как только я вижу статики в базовой архитектуре фремворка, то я уже знаю ряд задач/проблем, которые кроме как превышением вышеперечисленных критериев не решить. Одна из них, это RBAC.

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

[Евгений Педя]

Kir ---:
По существу моего вопроса вы не ответили. Получение квери билдера в контексте нужной модели без создания (ненужного) экземпляра модели - вполне норма. В данной ситуации и в других вызов статических методов оправдан.

Остальной текст является сплошным "бла бла бла", так как не имеет примеров в контексте laravel. Смысл что-то ещё обсуждать?

И да

[Kir ---]

По существу моего вопроса вы не ответили.

Ответил по существу. Но я не понимаю, почему вы не понимаете ответ. Возможно у нас с вами разный уровень понимания задачи программирования.
Скорее всего вы в самом начале профессии — программист

Answer 4

[index0h]

Symfony + Попросили проверить код, на что смотреть нужно?

Answer 5

[zugo]

Из личного опыта, вкратце:
1. Не используйте фасады, только dependency injection, благо автоматическое разрешение зависимостей в Laravel очень мощное и удобное.
2. Не используйте Eloquent, используйте Doctrine. *
3. Не стесняйтесь использовать асинхронные задачи. При желании можно с их помощью реализовать полноценный CQRS.

* - Если, конечно, в вашем представлении сущность бизнес-логики соответствует модели ORM, ведь DDD предполагает разделение "domain layer" от "persistence layer", хотя Doctrine ползволяет довольно безболезненно их смешивать. В любом случае, Eloquent - худшая часть Laravel, и, наверное, одна из самых неудачных реализаций ActiveRecord на PHP.

Comments

[Артур Гранд]

Подскажи лучшую ActiveRecord, коль ты знаешь

[zugo]

Артур Гранд: Встроенный в Yii определенно лучше, чем Eloquent (как пример), однако, в чем нужда использовать именно ActiveRecord? Некоторые довольно обоснованно считают, что это вообще антипаттерн (т.к. нарушает принцип "единственной ответственности"). А лучший DataMapper на PHP - это, безусловно, Doctrine.

Answer 6

[Евгений Педя]

Используйте Laravel и не беспокойтесь. Он построен на Symfony. Если понадобится, то использование Doctrine вместо/вместе с Eloquent возможно.

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

Laravel позволит быстро построить прототип. Изменить какие-то критичные части всё одно придётся. И это не отменит использование частей от Symfony.