По поводу методов в модели и их ответственности, это я так понимаю к 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
По поводу декларации свойств в моделях — ide-helper решает этот вопрос.
Что бы не брать только определённые поля из таблицы, это тоже можно указать при запросе. По идее в одной таблице не должно быть данных которые и нужны, и никогда не нужны приложению. В целом, по поводу «магий», если знать как она работает становиться в итоге проще чем без неё.
Да использовал Eloquent, нужды в Доктрине не чувствовал. Если нужно добавляю Репозитории, DTO…
В чём у Вас были проблемы с ActiveRecord при поддержке и масштабировании?
В статье описана обширность экосистемы фреймворка, что по моему мнению является его конкурентным преимуществом. Работаю с 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
Зашел почитать статью с интересом и желанием узнать другую точку зрения на то, что уже стало обыденным.
Прочитав, хочу сказать только одно… Критикуешь — предлагай! Никакой альтернативы, которая бы решала проблемы описанные автором, я здесь не увидел.
Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет
То что вы не видите разнцицу между статистическими вызовами и фасадами, это не говорит, о том, что это ничего не меняет. И если бы вы капнули поглубже документация рекомендует программирование по контрактам, предпочтительнее использования фасадов.
что документация и сообщество как раз таки поощряют писать говнокод
Когда мне начинают рассказывать, что на Laravel говнокодят, что Eloquent нарушает принцип единой ответственности и показывают тру «enterprise-like практики»(что бы это ни были в вашем понимании), аля отделение репозитория от модели и показывают количество кода для создания простой записи в базе со связями… Что толку от ваших «enterprise-like практик» и строгого следования тем же SOLID принципам, если на Laravel я реализую ту же логику в разы изящнее и в нескольких строках кода, в отличии от десятка строк на том же Symfony. Что наоборот делает код более поддерживаемым и понятным.
Люди забывают, что все эти принципы и практики, придуманы для того, что бы упрощать код, а не просто им следовать.
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 решает этот вопрос.
Что бы не брать только определённые поля из таблицы, это тоже можно указать при запросе. По идее в одной таблице не должно быть данных которые и нужны, и никогда не нужны приложению. В целом, по поводу «магий», если знать как она работает становиться в итоге проще чем без неё.
В чём у Вас были проблемы с ActiveRecord при поддержке и масштабировании?
То же самое и в 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
How do you divide page layout to components before start developing? Do you have something like «Component Criteria Checklist» from Evan You?
Прочитав, хочу сказать только одно… Критикуешь — предлагай! Никакой альтернативы, которая бы решала проблемы описанные автором, я здесь не увидел.
То что вы не видите разнцицу между статистическими вызовами и фасадами, это не говорит, о том, что это ничего не меняет. И если бы вы капнули поглубже документация рекомендует программирование по контрактам, предпочтительнее использования фасадов.
Когда мне начинают рассказывать, что на Laravel говнокодят, что Eloquent нарушает принцип единой ответственности и показывают тру «enterprise-like практики»(что бы это ни были в вашем понимании), аля отделение репозитория от модели и показывают количество кода для создания простой записи в базе со связями… Что толку от ваших «enterprise-like практик» и строгого следования тем же SOLID принципам, если на Laravel я реализую ту же логику в разы изящнее и в нескольких строках кода, в отличии от десятка строк на том же Symfony. Что наоборот делает код более поддерживаемым и понятным.
Люди забывают, что все эти принципы и практики, придуманы для того, что бы упрощать код, а не просто им следовать.