Какая архитектура кода правильная в laravel?

Рейтинг: 1Ответов: 1Опубликовано: 30.06.2023

Всем привет. Изучаю laravel и возник вот какой вопрос, подскажите опытные программисты, как правильно организовать код в Laravel?

Объясню, что имею ввиду. Сейчас смотрю уроки, читаю стать и заметил такую тенденцию, всё просто, регистрируешь путь, к нему подключаешь контроллер, при необходимости вешаешь middleware, а дальше в контроллере пишешь логику, например выгружаешь из БД данные о пользователе и возвращаешь результат в blade, распихивая по шаблону результат ответа... Т.е. практически во всех уроках код обработчика пишется в контроллере... Не так давно приходил представитель компании в учебное заведение и сказал, что писать обработку запроса в самом контроллере не правильно, если обработчик объемный, то это очень плохо, потому что в контроллере много методов и дальнейшая поддержка приложения будет затруднительна. И сказал, лучше обработчик выносить в отдельный класс, а в контроллере вызывать методы этого класса и возвращать результат, но не писать сам обработчик в контроллере...

Я вот не понимаю, как это сделать? Есть какой то инструмент для написания обработчиков в Laravel? Или это вообще чисто сами разработчики решают как назвать директорию, там создавать файлы с классами и описывать обработку там... Подскажите пожалуйста, как лучше и правильней построить архитектуру кода в Laravel?

laravel
Источник: Stack Overflow на русском

Ответы

▲ 1

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

Правильно сказано что весь код нельзя писать в контроллере. Да и вообще правильно всегда делить большой код на части (методы - функции). Что бы четко понять какой метод что делает. После этого потом разобрать код будет проще. И второе можно использовать те же методы в разных местах, если есть тому нужда.

Я пишу кода примерно так.

  1. В контроллере основная бизнес логика приложения.
  2. Есть разные сервисы (Services) в которых можно писать большую часть логики для приложения.
  3. Все что касается напрямую работы с базой данных, для этого есть репозитории (Repository). Для каждой модели есть репозитория. И если нужно работать с этой моделью оно делается через репозиторий.

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

Вот первая попавшая статья для логики репозиторий, о которой я говорил.

Надеюсь смог немного прояснить про сегодняшние тенденции написания кода на laravel.