Вчера я слушал новый эпизод Laravel Podcast с Тейлором Отвелом (Taylor Otwell), Джеффри Веем (Jeffrey Way) и Мэттом Стаффером (Matt Stauffer) – и они (наконец-то!) поговорили про создание больших приложений на Laravel, в последнее время этот вопрос очень часто задают.
Подходит ли Laravel, достаточно ли он взрослый, для больших проектов?
Так как ребята из подкаста не предоставили стенограмму, и прослушивание 50 минут может быть излишним, я решил написать краткое содержание и разбить ответы в более удобном формате Вопрос-Ответ, с ссылками по теме. Поехали!
1. Что такое большое приложение?
Мэтт: Прежде чем погружаться в тему, давайте определимся, что такое Enterprise приложение? Это о количестве строчек кода, о зависимостях, или безопасности, или о нагрузке?
Джеффри: у меня тот же вопрос. Какие функции/возможности имеют фреймворки, которые делают их энтерпрайзными, а Laravel нет? Имеет ли значение, что Zend имеет за собой большую компанию, тогда как про Laravel все спрашивают «что будет, когда Тейлор умрет?»
Тэйлор: я думаю, что большинство людей имеет ввиду множество классов, и, я полагаю, большое количество кода.
2. Так можно ли использовать Laravel для больших приложений?
Тэйлор: очевидно, я собираюсь сказать да, он может быть использован для больших приложений, потому что:
- Он уже используется для больших приложений, и мы знаем это.
- Laravel хорошо подходит для любых приложений, для которых подходит PHP. Здесь все зависит от вас – как только дело дошло до Контроллера, вы можете делать всё, что пожелаете.
- И еще я думаю что Laravel имеет уникальные преимущества и лучше подходит для создания больших приложений, чем другие PHP решения на текущий момент, по многим причинам. Главная — есть зависимости, сложность и DI в Laravel действительно хорош. Когда вы говорите о сложных приложениях, вы также имеете ввиду фоновую обработку задач, и Laravel единственный имеет встроенную систему очередей из всех основных PHP фреймворков. И еще, естественно, функции Event Broadcasting и другие, присущие большим приложениям.
Так что он не только может использоваться для больших приложений, он однозначно лучше подходит для больших приложений, чем прочие альтернативы на PHP.
Я понимаю, что это вводит в заблуждение, потому что Laravel имеет низкий порог входа. Но в тоже время он масштабируется в соответствие с вашими потребностями.
3. Люди иррациональны
Тэйлор: Между прочим, люди не выбирают фрейморк рационально. Много субъективных вещей. Может, им не нравится маркетинг, может они не любят дружелюбный стиль Laravel, так что они выбирают что-то более строгое, вроде Zend. Иногда им просто не нравлюсь лично я!
4. Мир энтерпрайза
Мэтт: говоря об энтерпрайзе, есть различия между большим и корпоративным проектом. У нас есть люди, постоянно говорящие «Генеральный директор, или совет директоров, или финансовый директор, или юристы, или кто-то еще из нашей многомиллиардной компании, очень обеспокоены тем, что мы собираемся вложить целую кучу времени и денег в Х», поэтому многие разработчики получают входные данные, не относящиеся к разработке, поэтому мне интересно, существуют ли какие-то ограничения, например, не использовать Laravel.
5. Приведите примеры больших приложений, использующих Laravel
Мэтт: давайте отойдем в сторону от энтерпрайза и поговорим о больших приложениях.
Я знаю, что мы не можем назвать много сайтов на Laravel. Я знаю несколько, потому что я под NDA с многими из них, и там тысячи миллионов посещений, из Alexa 500, много компаний из списка Fortune 500. Можем мы рассказать больше?
Тэйлор: различные сайты компьютерных игр, например, Fallout 4, используют Laravel на своих лендингах. Но основной вопрос – зачем людям нужны доказательства, что это работает? Доказательств всегда мало.
6. Дело не в фреймворке
Тейлор: Люди, возможно, хотят узнать: «если я создам свое большое приложение на Laravel, будет ли он вечно поддерживаться и обслуживаться, и … ?». Нет, Laravel не сделает автоматически ваше приложение крутым в поддержке в ближайшие 10 лет.
Фреймворк позволяет сосредоточится на вашем коде. Фреймворк — это маршрутизация, сессии, кеш, обращения к бд, но вы единственный, кто может описать специфику предметной области и знает проблемы бизнеса, которые намного сложнее, чем особенности фреймворка.
Мэтт: Плохой разработчик напишет плохой код на любом фреймворке.
7. Хорошо, как строить большие приложения?
Мэтт: Ну, предположим, люди согласны, что Laravel хорош. Как создать большое приложение, какие нюансы в приложении с миллионами просмотров в неделю?
Тэйлор: Достаточно просто. Убедитесь, что вы используете хороший драйвер для сессий и кеша, вроде Memcached или Redis, на сервере вроде Elasticcache на вашем AWS.
Вероятно, вам нужен балансировщик нагрузки, PHP очень хорошо масштабируется в этом смысле.
На уровне Laravel, убедитесь, что вы используете config:cache, route:cache, что вы сделали composer dump-autoload –optimize.
Джеффри: На Laracsts, который, внезапно, тоже хайлоад-проект, я не делал столько всего! Есть многие базовые вещи, которые люди полностью игнорируют, например, размеры их картинок!
Тэйлор: другая хорошая идея – отделить вашу БД от сервера приложения. Это позволит проще масштабироваться, например, если вам потребуется второй сервер.
И, говоря о кешировании, я много использую Cloudflare в последнее время. Весь официальный сайт Laravel жестко закеширован, только несколько запросов на самом деле достигают сервера, потому что почти все статично, например, документация.
Мэтт: С Cloudflare есть другая проблема: необходимо учитывать срок хранения, чтобы обновлять кеш. Так что это даже не проблема Cloudflare, а ваша – проверяйте Expires в заголовках!
Вместо заключения
Выслушав их мысли (спасибо, ребята!), я пришел к тому же выводу – что большие приложения это не про фреймворк, здесь есть еще много предметов для обсуждения: DevOps, механизмы кеширования, уникальная бизнес-логика вашего приложения, структура БД и так далее. Так что вопрос «Достаточно ли хорош Laravel?» — это неправильный вопрос. Лучше спросите, «Достаточно ли хорош мой код?», или «Достаточно ли у меня навыков использовать Laravel эффективно в большом приложении?». Если есть что добавить, то автор статьи принимает комментарии в своем блоге, и вот ссылка на сам подкаст.
От себя добавлю: сама суть обсуждения достаточно дискуссионна, и во многом я не согласен с категоричностью Тейлора (каждый поп хвалит свой приход, да), но основная мысль, которая сквозит через подкаст — плохой разработчик напишет плохой код, вне зависимости от фреймворка. Фреймворк лишь дает инструменты для того, чтобы сосредоточится на основном — бизнес-логике.
P.P.S: Об ошибках и неточностях сообщайте, пожалуйста, в личку.
Комментарии (49)
Agel_Nash
14.05.2017 21:31-1На Laravel действительно очень много сайтов.
В том числе государственных и образовательныхhttp://veterans.arkansas.gov/
http://sailau.orda.gov.kz
http://innovation.bsmu.edu.ua/
http://iutoic-dhaka.edu
http://beaufortccc.edu
http://lstc.edu
http://northwood.edu
http://amda.edu
http://aksaray.edu.tr
http://statuschecker.fgdc.gov
http://zhanakorgan.gov.kz
http://tika.gov.tr
http://istanbulhalksagligi.gov.tr
http://teplo.gov.ua
http://president.gov.ua
http://pz.gov.ua
samizdam
14.05.2017 22:58+2Суть в том, что в интернете, на данный момент действительно много сайтов. И на ларавел достаточно. И на юии множество. И на симфоне, зенде до фига. И на, прости Господи, водпрессе просто многие миллионы, в том числе хайлоад, образование, гос.сектор ещё все угодно.
Agel_Nash
15.05.2017 16:49Своим комментарием я лишь хотел поделиться списком сайтов на Laravel
SamDark
15.05.2017 18:50Если не секрет, как был составлен список?
Agel_Nash
15.05.2017 20:23По наличию куки laravel для 4.х ветки и laravel_session для 5.х. Как правило, параметр config(session.cookie) редко кто переопределяет
VolCh
14.05.2017 22:31-2Как по мне, то одним из определяющих свойств современного энтерпрайз-реди фреймворка, является возможность сменить его частично (прежде всего уровень персистетности) или полностью на другие реализации, не затрагивая особо код бизнес-логики. Когда последний раз (давно) смотрел Ларавел впечатление сложилось, что всё очень сильно и жёстко связано.
Fesor
14.05.2017 23:41К Laravel вполне легко прикрепить что-либо другое для персистенса. Остальное не так критично и в целом норм. Меня дико напрягает структура самой ларавели и разбиение на модули, но не так плохо как было скажем в 4-ой версии.
Big_Shark
15.05.2017 03:24Разбиение на модули? О чем это ты?
Fesor
15.05.2017 12:25вопрос связанности. Зачем например моим ивентам знать что-то об очередях? Или же зачем очередям быть настолько завязанным на конкретной реализации компонента для консольных приложений? Или зачем вводить тупой нэймспейс
Contracts, он особо бесит. Хотя возможно кому-то так проще жить.
saggid
15.05.2017 01:03+1Там же без особых проблем любую подсистему можно заменить, ибо всё на сервис-провайдерах построено, список которых задаётся в конфиге вашего проекта. Можно любой из сервис провайдеров заменить на свою собственную реализацию, такую, какая вам лично будет необходима.
Для меня лично это является основным плюсом архитектуры ларавел: она позволяет мне без проблем менять логику работы фреймворка в ту сторону, в какую нужно именно мне в именно этом конкретном проекте.
greabock
15.05.2017 14:52Нельзя "без особых проблем" заменить службы маршрутизации и событий. Потому как эти базовые провайдеры загружаются на очень раннем этапе, и сам фреймворк очень сильно завязан на свою систему событий. Все остальное действительно подключается/отключается без танцев с бубном.
saggid
15.05.2017 18:42Если смотреть на код пакета Dingo\Api, то можно увидеть, что они не заменяют маршрутизатор Laravel, но вместо этого дополняют его своим собственным, что, похоже, тоже имеет право на жизнь.
greabock
16.05.2017 14:02+1Ну, Динго — вообще костылище, каких поискать. Количество "хаков" в этом пакете зашкаливает )
Начиная с условного объявления классов, заканчивая подменой маршрутизатора в контейнере. Возможно, что большинство стандартных кейсов он покрывает без проблем, но нам он не подошел.saggid
16.05.2017 17:50И вы решили писать всё самостоятельно?
greabock
16.05.2017 18:48+1Строго говоря, не так уж самостоятельно. Всё собирается из абсолютно тех же зависимостей (ну или почти тех же), но уже под своим соусом. Само собой, это самое "всё" решает именно наши задачи, без претензий на универсальность.
Fesor
14.05.2017 23:41+4Что такое большое приложение?
мерять проекты количеством строк кода или классами — так себе. Я видел вполне себе огромные проекты которые на самом деле были просто кучей CRUD-а. И наоборот, небольшие проекты для которых приходилось держать довольно большую команду.
По факту следует больше ориентироваться на предметную область проекта. Это что-то сложное (это никак напрямую не связано с размером), возможно с организационной точки зрения нежели с технической, и обычно с довольно большим сроком службы.
Главная — есть зависимости, сложность и DI в Laravel действительно хорош.
немного не понятно сформулирована фраза. Ну и чем это отличается от того же zend или symfony? то что DI контейнер в Laravel неплох — это факт. Ну а в symfony к примеру еще и анализ зависимостей можно провести в компайл тайм. Тут кому что нужно.
встроенную систему очередей из всех основных PHP фреймворков
не систему очередей, а возможность быстро их прикрутить. Для небольших проектов — золото. А для чего-то посерьезнее всеравно придется ставить доп пакеты с поддержкой amqp к примеру. Ну и опять же, сделать
composer requireв наши дни не так уж и сложно.
Единственное что реально является плюсом — возможность событие прокинуть в очередь… и то, мне не очень нравится необходимость для этого имплементить интерфейс на уровне ивента. Проще подсунуть крутым контейнером зависимостей которй он расхваливает другую реализацию ивент диспатчера
Иногда им просто не нравлюсь лично я!
а вот это в точку.
существуют ли какие-то ограничения, например, не использовать Laravel.
вы тут как будто бы задаете вопрос. Конечно таких ограничений нет. Если мы говорим про рынок в Штатах то там это наоборот приветствуется. Маркетинг он такой а люди не иррациональны. Как-то раз нас клиент попросил заюзать neo4j хотя прямой необходимости в этом не было… просто клиент услышал что это круто.
- Приведите примеры больших приложений, использующих Laravel
Лэндинги на laravel — большой проект, это уж точно. В целом лично я знаю парочку крупных проектов использующих laravel. Те кто не страдают — просто используют его только там где это уместно а все остальное и важное вообще на python реализовано. А дальше все от специфики зависит. Если приложение большое но оно тупо data-cetric то как бы все будет хорошо.
- Хорошо, как строить большие приложения?
горизонтальное масштабирование и кэширование для чайника? мдя.
«Достаточно ли хорош мой код?»
достаточно ли он отделен от фреймворка.
ellrion
15.05.2017 12:07Наверное выражу непопулярное мнение, но лично мне Лара нравится именно "гибкостью" в плане подхода к коду. Т. е. на ней легко писать очень быстро маленькие приложения сильно отходя от академичных подходов (тобишь с долей говнокода). Прекрасно получается писать средние приложения возможно добавляя какие то свои архитектурные коснтрукции при этом так же местами забивая на академичность. Ну и ничего не мешает строить поверх свои архитектурные решения и идти страшным энтерпрайз путем) При этом вполне получается идти от первого к последнему рефакторингом.
Fesor
15.05.2017 12:23от академичных подходов
меня всегда напрягает формулировка "академические подходы". Что это для вас, вот чисто ради статистики.
ellrion
15.05.2017 12:39+1Ну например SOLID. Прекрасный набор принципов. И Их соблюдение важно. Но тот же AR их нарушает весьма сильно (особенно S). И в небольших приложениях это дает простоту архитектуры и скорость разработки. То же самое и с внедрением зависимостей например в контроллеры. Я например отделяю для себя сервисы инкапсулирующие бизнеслогику и сервисы окружения так сказать. И вот их я явно не буду пробрасывать через внедрение зависимостей а могу просто использовать хелпер (например view) или или извлеку из контейнера прямо в коде метода. И т. д.
Fesor
15.05.2017 17:51+1Но тот же AR их нарушает весьма сильно (особенно S).
зависит от контекста. Если AR используется исключительно как модель данных и не содержит бизнес логики, относится исключительно к persistence layer, то как бы я не вижу тут сильного нарушения SOLID.
Другое дело что люди начинают пихать туда бизнес логику… для простых случаев, коих большинство, все будет хорошо. Но как только у нас набирается весьма сложная бизнес логика требующая работы с графом объектов, AR будет только мешать.
Но тут проблема не с AR, есть куча других подходов. например row data gateway который можно применить для устранения проблем с AR и получить вполне изолированную логику. Проблема в людях которые просто привыкли использовать один инструмент и не рассматривают другие варианты. И это могу вам сказать серьезная проблема и я понятия не имею как это лечить. Это как юзать ORM там где удобнее взять SQL и наоборот.
Так же сам по себе принцип SRP весьма бесполезен. Лучше на OCP концентрировать внимание так как цель SRP как раз таки OCP. У меня порой складывается впечатление что SRP был добавлен в SOLID тупо что бы получалось SOLID а не OLID.
а могу просто использовать хелпер (например view)
это сервис локатор. И если ваш фреймворк умеет дабл диспатч в контроллеры (laravel например) то через DI это проще и легче контролировать что в контроллерах ровно то что надо а не все подряд. Скажем в symfony этого из коробки нет, хотя с версии 3.3 можно будет за 10 строк добавить.
или или извлеку из контейнера прямо в коде метода.
Это более чем "академично". Просто не так удобно. Но явно удобнее чем "контроллеры как сервисы".
SamDark
15.05.2017 18:56Что значит "сильного" нарушения SOLID? Или нарушается или не нарушается. AR по определению его нарушает и создан чтобы его нарушать. Мы тут не говорим про то, в каком что слое используется и дёргается ли
->save()по поводу и без.
Проблема в людях которые просто привыкли использовать один инструмент и не рассматривают другие варианты. И это могу вам сказать серьезная проблема и я понятия не имею как это лечить.
Заниматься просвещением в меру сил и возможностей. Больше вариантов не вижу.
Так же сам по себе принцип SRP весьма бесполезен. Лучше на OCP концентрировать внимание так как цель SRP как раз таки OCP. У меня порой складывается впечатление что SRP был добавлен в SOLID тупо что бы получалось SOLID а не OLID.
Так и есть. SOLID — маркетинговый ход нескольких известных консультантов, которые смогли продать старый-добрый cohesion/coupling под новым именем.
Fesor
15.05.2017 20:53AR по определению его нарушает и создан чтобы его нарушать.
Вот скажите, если у меня объект реализующий AR тупо представляет таблицу в базе и не содержит никакой бизнес логики, какой из принципов SOLID он нарушает? SRP в данном контексте он не нарушает, так как у этого объекта одна единственная причина для изменений.
Да, он нарушает — LSP. Но это можно пофиксить заменив наследование трейтом который будет делегировать логику другому объекту. Тогда у нас просто исчезнут "подтипы".
Да, он нарушает DIP так как подразумевает глобальный доступ к зависимостям. Но опять же… можно реализовать сервис локатор который будет обращаться к адаптеру и тем самым мы будем иметь возможность подменить реализацию нижестоящую.
Статические методы-фабрики которые работают с глобальным стэйтом — можно их убрать в отдельный компонент finder.
Как по мне больше проблем от репозиториев с методом save чем от AR использующегося как data model. Хотя тут опять же от контекста зависит.
старый-добрый cohesion/coupling под новым именем.
именно так. Ну и еще information hiding и GRASP. С последним к слову грустно, про grasp мало кто знает. Не на слуху.
VolCh
16.05.2017 08:05зависит от контекста. Если AR используется исключительно как модель данных и не содержит бизнес логики, относится исключительно к persistence layer, то как бы я не вижу тут сильного нарушения SOLID.
Тогда это не AR. Смысл этого паттерна именно в совмещении бизнес-логики и логики хранения.
SamDark
15.05.2017 14:58Подозреваю, я виноват в распространении формулировки. Под ней я всегда понимал «слепое следование паттернам и принципам, нужны они или нет».
SamDark
15.05.2017 15:00Очень удивлён тем, что авторы Laravel не смогли привести примеров крупных проектов. У того же Yii примеры были ещё когда он был версии 1.0, а теперь есть ещё и каталог http://yiipowered.com/ru, где, конечно, далеко не всё, но крупные присутствуют.
Fesor
15.05.2017 17:52не смогли привести примеров крупных проектов.
я думаю стоит посмотреть оригинальный подкаст, ибо что-то мне подсказывает что 80% информации упущено в тексте.
SamDark
15.05.2017 18:50Подозреваю, что так и есть надо будет послушать. Тейлор — прекрасный маркетолог и как любой маркетолог, должен был быть готов к этому вопросу. Поэтому я и удивился.
Agel_Nash
15.05.2017 20:40+1Альфа-форекс из каталога Yii сделан на OctoberCMS, которая базируется на Laravel. Вывод этот сделан на основе cookie, а так же по наличию пол года назад вот такой ошибки, характерной для плагина ProBlog.
Так что актуальность каталога под большим вопросом.Agel_Nash
15.05.2017 20:53+1Из крупных на Yii 1.x есть mts.ua, tass.ru, livecoin.net и т.д. Если кому-то интересно, то вот
список (126) того, что мне удалось обнаружить на Yii 1.xmagneticsystem.biz
modelcard.biz
traveling.by
beorganic.by
autotovar.by
evna.by
cian.bz
keep2share.cc
escape2poland.co.uk
villabaku.com
vagondom.com
luuk.com
pechatnick.com
solar-staff.com
recordrentacar.com
sevas.com
technosider.com
skype-language.com
sequenom.com
gsmpress.com.ua
tfd.com.ua
doctorsam.com.ua
artex.com.ua
toys.com.ua
atlant2k.com.ua
sunshouse.com.ua
pyha.fi
tomsk.gov.ru
arbalet.in.ua
timeua.info
goroskopy.info
utes.krym.ru
ng.krym.ru
30let.krym.ru
ndk.kz
halykbank.kz
islam.kz
astana-motors.kz
inkaraganda.kz
profinance.kz
hyundai.kz
mazhab.kz
fanart-central.net
telgraf.net
socialchance.net
livecoin.net
odpublic.net
mafii.net
capitalist.net
hit-season.net
cor.org
artalbum.org.ua
lipetskcity.ru
medialipetsk.ru
tass.ru
milady-24.ru
psyonline.ru
postila.ru
rivierarealty.ru
lapana.ru
afkstroy.ru
doc4web.ru
cs-garant.ru
9months.ru
informpskov.ru
aioncataclysm.ru
romashka96.ru
medi.ru
tuning-parts.ru
38mama.ru
test-drive.ru
arafnews.ru
pozitivmag.ru
lacywear.ru
zapchastivoz.ru
photosight.ru
snyat-kvartiru-bez-posrednikov.ru
1ul.ru
word-to-html.ru
2mm.ru
karofilm.ru
tripsmile.ru
zasmeshi.ru
city-mobil.ru
zamos.ru
uztt.ru
pedigree.ru
kurgan.ru
mobi03.ru
1pnz.ru
lozahobby.ru
krym.ru
hellride.ru
socialchance.ru
zhonga.ru
smapse.ru
nasko.ru
mz-clinik.ru
nskgortrans.ru
joystick.ru
pxel.ru
bazametrov.ru
jessnail.ru
zanostroy.ru
autotuning-bmw.ru
auto-camera.ru
oliu.ru
aioninfinite.ru
avtoschetki.ru
belwest.ru
novostroy.ru
bestactor.ru
kniga-stroitelia.ru
kuponator.ru
elisdn.ru
novostroy.su
nedvizhimost.tk
robinzon.tv
apa.tv
anifilm.tv
1game.ua
apltravel.ua
hosting.ua
mts.ua
pay.vn.ua
xn--80ajbzh4e.xn--p1aiSamDark
15.05.2017 22:29Сайт может и на October, но сама система на Yii. Надо будет URL там поправить и скриншоты, чтобы не путали...
SamDark
15.05.2017 22:35Поправил.
Agel_Nash
15.05.2017 23:13Спасибо.
Дико не удобный ЛК этого альфа-форекса:-)SamDark
15.05.2017 23:28Мне тоже не очень нравится… интересно, куда они фидбек на эту тему принимают...
Agel_Nash
15.05.2017 23:33+1Никуда. Им многие уже писали в службу поддержки через ЛК. На что приходят отписки в стиле «спасибо, мы учтем ваши пожелания». Время идет, пожелания не учитываются. Даже эту проблему с отображением служебной информации исправляли несколько месяцев.
devg
15.05.2017 16:23Да, в крупных приложениях главное, как ты пишешь бизнес-логику предметной области. Хорошо спроектированная бизнес-логика обычно легко переносима между фреймворками.
Для меня критерий применимости фреймворка для крупного проекта — степень следования рекомендациям PHP-FIG.
SamDark
15.05.2017 18:48PHP-FIG вообще никакого отношения к размеру проектов не имеет. Говорю как его участник.
debugger84
После Zend 2 и Symfony 2 пришлось на новой работе работать с Laravel 5. Проект довольно большой по объему кода. Сначала думал, что проект плохо написан, после прочтения кучи статей — понял, что код проекта похож по стилю на код, который в любом примере по ларавелю можно найти (статические вызовы везде по коду, компоновка запроса к БД прямо из контроллера, да и где угодно по коду).
Думал как улучшить код — ввести расслоение кода, прокидывать все зависимости через конструктор или сеттеры, а не вызывать статические методы фасадов, выкинуть Eloquent и подключить Doctrine 2, выкинуть блейд, разделить код на модули, чтобы по паре сотен файлов не лежало в директории с контроллерами и столько же с моделями. Но тогда не понятно что остается от фреймворка — получается такая себе Symfony 2.
В итоге для себя решил, что все-таки Laravel не подходит для проектов с большим объемом кода, раз из него, в таком проекте, сильно хочется сделать другой фреймворк, значит тот другой — гораздо лучше подходит для организации кода в большом проекте.
OnYourLips
Аналогично делали. В итоге поняли, что от Laravel останется только набор компонентов, причём компонентов от Symfony будет больше.
И Eloquent — это то, от чего в первую очередь надо избавляться, абсолютно неподдерживаемая библиотека.
В итоге большой проект на Laravel — это просто Symfony с небольшим количеством Laravel-компонентов (очереди и т.д.)
vlakarados
На 100% моя ситуацния, правда, на тот момент еще с 4ой версией.
TooZ
Ни кто ведь не заставляет писать все в контроллеры, легко можно перенести всю бизнес логику в модель, валидацию вынести отдельно, поэтому и написано все зависит от того кто пишет. Хоть и в официальной документации конечно примеры не совсем по стандарту и новички начинают приучаться писать кривенький код.
n1ks2n
У меня для вас плохие новости, но то что вы описали как раз и является примером фрактала плохого кода. А именно ТТУК и прочие фишечки. Примеры кода в документации Laravel приведены as is с использованием Facades, которые в большинстве случаев не используются напрямую в правильном коде, для введения дополнительных объектов существует крайне умный DI, что так же повышает тестируемость кода. Структурированием кода так же занимается программный архитектор/ведущий разработчик/тимлид. Да Laravel дает довольно много свободы в плане написания кода и очень редко заставляет вас писать код по шаблону. Поэтому написание крупных, да и вообще нормальных проектов на Laravel требует серьезной дисциплины и понимания. Если вам требуется погонщик с хлыстом, чтобы не сходить с right way, то тогда Laravel не для вас. А вообще холиварить на эту тему можно долго, но статистика говорит об обратных цифрах. с 2015 года Laravel бьет все рекорды по популярности в мире PHP, как для пет-проектов, так и для рабочих, просто в Западном мире. И даже не стоит отрицать того факта, что платная подписка на Laracast дает кучу видеоуроков крайне полезных с best-practice разработки, где люди на пальцах рассказывают про TDD, BDD и грамотное проектирование и работу с проектом, которые кстати вы можете спокойно перенести в работу с другими фреймворками.