Ох уж эти архитектурные решения. Отдельный самописный фреймворк внутри лары -- это да. Но соглашения есть на каждом проекте. И проверенные шаблоны проектирования, верю, никто клеймить не будет. И разделение кода на слои.
Это чуть другая оптика, но Laravel не защищаю, вы приводите ценные и конкретные фактические наблюдения. Ежедневно сталкиваюсь с тем, как косячно там всё под капотом функционирует.
Laravel может быть "только для MVP", это не отменяет развилку для развивающегося проекта: 1) пишем плохо на Laravel, 2) пишем умно рядом с на Laravel 3) пишем умно без Laravel.
Моя статья исходит из допущения, то уже выбран путь 2. На этот выбор влияет масса в том числе внетехнических условий.
Laravel не просто «тупая штука для MVP с низим порогом входа». Это гибкий инструмент, склоняющий, но не настаивающий на ненадёжных архитектурных решениях. Внутри как вы правильно написали это просто фреймворк, инфраструктурный код. Симфони тоже — инфраструктура.
Разделение на слои упирается не в фреймворк, а в понимание программистами правил композиции своего кода. В Симфони тоже надо постараться, чтобы слои не оказались перемешаны.
Будет ли качественным код, зависит от качества программистов, а не фреймворка. И бизнесу решать, кого на какой проект нанять. Я вот показал, как улучшить качество кода на Ларавеле, если не стоит бизнес цель всё переписать.
Ну, помимо «субъективно правильного» можно коммуницировать кодом с членами команды посредством шаблонов проектирования, правил композиции и стратегиями типа DDD :)
Пишу, что кроме разделения на массив удобно правила валидации убрать из презентационного слоя. Парадоксально, но на ларе сделать это проще, чем на симфони.
Если не стоит бизнес цель всё переписать красиво с одной стороны, а с другой стороны нужно, чтобы большой проект работал и развивался, то вам понадобится дополнительный уровень профессионализма на ларе, чтобы писать качественный код.
Ох уж эти архитектурные решения. Отдельный самописный фреймворк внутри лары -- это да. Но соглашения есть на каждом проекте. И проверенные шаблоны проектирования, верю, никто клеймить не будет. И разделение кода на слои.
Это чуть другая оптика, но Laravel не защищаю, вы приводите ценные и конкретные фактические наблюдения. Ежедневно сталкиваюсь с тем, как косячно там всё под капотом функционирует.
Laravel может быть "только для MVP", это не отменяет развилку для развивающегося проекта: 1) пишем плохо на Laravel, 2) пишем умно рядом с на Laravel 3) пишем умно без Laravel.
Моя статья исходит из допущения, то уже выбран путь 2. На этот выбор влияет масса в том числе внетехнических условий.
Рад, что заценили!
Laravel не просто «тупая штука для MVP с низим порогом входа». Это гибкий инструмент, склоняющий, но не настаивающий на ненадёжных архитектурных решениях. Внутри как вы правильно написали это просто фреймворк, инфраструктурный код. Симфони тоже — инфраструктура.
Разделение на слои упирается не в фреймворк, а в понимание программистами правил композиции своего кода. В Симфони тоже надо постараться, чтобы слои не оказались перемешаны.
Будет ли качественным код, зависит от качества программистов, а не фреймворка. И бизнесу решать, кого на какой проект нанять. Я вот показал, как улучшить качество кода на Ларавеле, если не стоит бизнес цель всё переписать.
Всё так. Конечно мой текст для ситуации, когда проект вырос, но переписывать с нуля не хочется.
Только отмечу, юнит тестирование в Ларе организовать несложно. Гибкий ведь инструмент.
Ну, помимо «субъективно правильного» можно коммуницировать кодом с членами команды посредством шаблонов проектирования, правил композиции и стратегиями типа DDD :)
Пишу, что кроме разделения на массив удобно правила валидации убрать из презентационного слоя. Парадоксально, но на ларе сделать это проще, чем на симфони.
Если не стоит бизнес цель всё переписать красиво с одной стороны, а с другой стороны нужно, чтобы большой проект работал и развивался, то вам понадобится дополнительный уровень профессионализма на ларе, чтобы писать качественный код.