Как стать автором
Обновить

Комментарии 24

очень полезно, спасибо

За последние лет 6 два проекта из четырёх (включая текущий) на Laravel 5.x. Не понимаю его "отличности". В теории вроде можно писать приложения и (микро)сервисы так, чтобы кодовая база не вызывала постоянные WTF, особенно если отказаться от Eloquent или тщательно его изолировать.


Но, блин, никто не хочет писать так, чтобы фреймворк обеспечивал только инфрастрктуру, не вылезая в бизнес-логику:


  • сильная связанность: статические и магические методы, глобальные функции, как условно чистые, так и держащие в себе всё, по сути, приложение
  • магические модели сущностей, где в коде классов этих сущностей нет упоминания их свойств (хорошо если phpdoc @property добавлены), а сами свойства публичные
  • сплошь и рядом какие-то массивы с магическими, опять таки, шейпами и значениями
  • связь кода со схемой базы данных отсутствует как класс — миграции вещь в себе, легко заменяемая на чистые SQL инструменты, генерации миграции по диффу схем нет. Собственно схем нет, не говоря об их связи с кодом.
  • интеграция с IDE слабая, IDE-helper и Co являются генераторами костылей по сути. И не всегда корректными и(или) полезными

Коммьюнити очень сильно повернуто на видео, хоть на спецресурсах, хоть на So, хоть в этом посте. Активно пушатся коммерческие сервисы на каждый чих.


Вот как вы можете считать это отличным? Как можно писать что-то серьёзное, если никто (почти) не хочет банальный SOLID соблюдать?


Извините, накипело. Может секрет какой-то есть?

НЛО прилетело и опубликовало эту надпись здесь

Так я же и говорю: вроде бы можно, но никто (почти) не хочет.


Ну, такие массивы как критерии или правила валидатора.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

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


Про Симфони я разве что-то писал? :) Ну и с выходом flex, как мне кажется, для чего-то сложнее Restish CRUD приложений или сервисов, будет сопоставимо по времени для MVP, но с разным фокусом распределения этого времени: поиск и адаптация существующих универсальных высокоуровневых решений под задачу против написания ускоспециализированных.

интеграция с IDE слабая, IDE-helper и Co являются генераторами костылей по сути. И не всегда корректными и(или) полезными

Может потому, что основные разработчики используют Sublime Text или Atom? Ну, например, насколько помню, во всех видео на Laracasts используется простой текстовый редактор.

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

По умолчанию лара настроена на проекты небольшого размера или проекты из серии сделал и забыл и в этом она хороша. Однако, она позволяет без боли отказаться от некоторых вещей в пользу более «правильных» подходов и за это её тоже любят.
Глобальные функции, фасады и прочие хелперы необязательны, всё доступно через контейнер.
Не хотите eloquent, ставьте доктрину.
Про массивы не очень понятно, но наверное вы имели ввиду коллекции. Штука в общем то удобная, но совершенно необязательная.
Коммерческие сервисы пушатся и это хорошо, пусть будет платная инфраструктура для тех кому она нужна, остальным она не мешает.

Но, блин, никто не хочет писать так, чтобы фреймворк обеспечивал только инфрастрктуру, не вылезая в бизнес-логику

Так это проблемы в головах, а не в инструменте ;)

Я знаю как можно. Про массивы я имел в виду всякие штуки вроде правил валидаторов, условия поиска, атрибуты "модели" и т. п. Вон взгляните на https://habr.com/en/company/otus/blog/471776/ — там десятки массивов в коде, хотя в задаче ничего про массивы, списки, какие-то коллекции нет.


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

Я вас понимаю.

По ссылке код бедовый, прямо скажем, и дело не в ларе =)

Аргумент про провокацию из серии: её изнасиловали потому, что она была одета вызывающе. Может это и справедливо отчасти, однако, преступник тут очевиден.

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

Давно известная проблема: если по умолчанию конфигурация, документация, какие-то официальные и полуофициальные гайды демонстрируют "быстро", а не "хорошо", то подавляющее большинство будет писать "так в гайдах". Причём не обращая внимание про что конкретный раздел гайда. Например, из раздела о работе с БД начнут копировать способы работы с контроллерами и валидаторами.


Давеча тут еле убедил человека, что нет в PSR требований делать суффикс Interface, просто он везде в примерах и реализациях, но требования такого нет.


А есть под рукой ссылочка на это проект?

На правах флейма: "40 лучших инструментов" обычно означает, что в самом фреймворке не хватает практически всего.

ну как то совсем толсто )
В статье описана обширность экосистемы фреймворка, что по моему мнению является его конкурентным преимуществом. Работаю с Laravel, в том числе, уже достаточно давно и ни в одном другом фреймворке (не в зависимости от языка), ещё не видел такое обширное количество готовых решений вокруг. Это как Apple. Сегодня уже никто не любит Apple, только за iPhone, люди любят эту экосистему: iPhone + iCloud + AirPods + Apple Music +…
То же самое и в Laravel: Laravel Framework + Laravel Forge + Envoyer + Laracasts +…
Всё в сообществе делается максимально developer friendly. Мне лично доставляет большое удовольствие работать с инструментами экосистемы.
Ещё вижу здесь популярное мнение, я бы даже сказал заблуждение, о том, что Laravel хорош только для мелких и средних проектов и что он не конкурент для Symfony. Не могу согласиться. У меня есть опыт работы с проектами на Laravel и больших и небольших масштабов, радует в обоих случаях.
На эту тему можно послушать подкаст с известными членами сообщества вместе с Тейлором:
Laravel Podcast Bigger & Better
и ещё несколько статеек:
laraveldaily.com/matt-stauffer-laravel-enterprise-ready
laraveldaily.com/can-laravel-used-big-enterprise-apps-summary-laravel-podcast
рекомендации по организации кода:
stitcher.io/blog/organise-by-domain
stitcher.io/blog/laravel-beyond-crud
У меня есть опыт работы с проектами на Laravel и больших и небольших масштабов, радует в обоих случаях.

На больших масштабах (в плане количества кода, сложности бизнес-логики) использовали Eloquent? Я вот как-то вывел эмпирическое правило: если на проекте на любом языке, фреймворке используется любая имплементация ActiveRecord в качестве основного средства абстрагирования от SQL, то на средне-больших масштабах жди беды с поддерживаемостью и развитием скорее рано чем поздно.

Да использовал Eloquent, нужды в Доктрине не чувствовал. Если нужно добавляю Репозитории, DTO…
В чём у Вас были проблемы с ActiveRecord при поддержке и масштабировании?

Часто банально непонятно какой-то метод относится к бизнес-логике или к логике хранения. И довольно часто встречается что-то вроде:


public function activate() {
  this.status = 'active';
  this.save();
}

то есть не просто две ответственности у класса by design AR, а и у методов две отвественности: изменить стейт объекта и залезть в базу для чего-то.


Ну и такие мелочи как встраивание ValueObject очень не тривиальны в ActiveRecord в целом.


Конкретно Eloquent не нравится ещё и своей магией: в самом классе никак свойства (атрибуты) незадекларированы, при этом публично доступны. Собственно по исходному коду вообще не понять, а какие свойства есть собственно у объекта: он, грубо говоря, при инициализации лезет в базу и смотрит, какие поля там есть и тупо их себе копирует. Есть в таблице поле, которое приложению не нужно (например, дата последнего бэкапа, которая в логике приложения не участвует вообще) — оно будет и в объекте.

Ответил ниже
По поводу методов в модели и их ответственности, это я так понимаю к SRP принципу. Многие ругают Eloquent за якобы нарушение этого принципа, но это скорее не верная трактовка принципа SRP. В целом формулировка принципа SRP вводит в заблуждение. Можно посмотреть небольшой thread на эту тему с участием Дяди Боба (который придумал SOLID) и Тейлора (создатель Laravel):
twitter.com/taylorotwell/status/1023223691465748480

Не стоит забывать, что все принципы и паттерны придуманы для того, что бы упрощать систему, а не просто что бы соблюдать. Если соблюдение только усложняет код, то лучше пренебречь.
Как понять какой метод относится к бизнес логике? Любой не из стандартных: save, update, delete… Не вижу никаких проблем с таким методом activate.
Если чуть углубиться в то, как в сообществе Laravel пишут код, так что бы с ним работать было максимально просто, то вот замечательный доклад на Laracon, я собственно придерживаюсь того же подхода:
www.youtube.com/watch?v=dfgtKb-VpRk

Решений с ValueObject достаточно для Eloquent + Null Object pattern есть из коробки для связей:
laravel.com/docs/6.x/eloquent-relationships#default-models

По поводу декларации свойств в моделях — ide-helper решает этот вопрос.
Что бы не брать только определённые поля из таблицы, это тоже можно указать при запросе. По идее в одной таблице не должно быть данных которые и нужны, и никогда не нужны приложению. В целом, по поводу «магий», если знать как она работает становиться в итоге проще чем без неё.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории