@SVZhidkow
Бэкенд-разработчик

А какой шаблон проекта на Laravel у Вас?

Всем привет.
Не первый год в веб разработке, несколько последних лет использую Laravel (что греха таить, нравится он мне), прочитал много умных книг и статей. Вроде бы и принципы ООП понятны и все фишки с репозиториями и сервис-контейнером в Laravel'e. И много проектов мной на нем написано, которые были легко масштабируемы, легко внедрял в них новые фичи и менял логику по требованию заказчика. Но все-равно постоянно присутствует чувство какой-то неудовлетворенности)) Кажется, что шаблон самого приложения может быть еще чище и изящнее. В связи с этим два вопроса, чтобы выяснить, а как вы их для себя решаете:

1. Котроллеры. Везде пишут, что контроллер должен содержать минимум кода, не должен знать, как модель получает информацию, и как представление ее отображает. Но как это правильно реализовать в рамках Laravel? Основная трудность в данном пункте – как правильно передавать данные в представление? Т.е. один и тот же метод контроллера может выводить данные, скажем, во view шаблон, а может и в json’e отдавать. Как это правильно реализовать? Я вижу тут 2 способа:

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

- метод контролера один, но используется GET переменная «json», скажем. Добавляем блок if, если переменная присутствует, то отдаем json, иначе отдаем view. Но тоже, как-то не кошерно смотрится…

Как быть?

2. Модели. То, что в Laravel называется моделями, не подходит на роль бизнес логики приложения, я прав? В моделях задаются «настройки» работы с конкретной таблицей БД, при этом можно сделать массу удобных штук с отношениями, сделать очень удобные скоупы. Но при этом модель может разрастись еще до того, как мы начнем в нее внедрять какие-то особенные именно для данного проекта методы бизнес логики. Т.е. логику желательно куда-то вынести. Часто видел и сам так делал, что просто выносят в App\Services. Но тоже до конца не понятно, как правильно вынести? Должны ли это быть самостоятельные классы, ничего не знающие про Eloquent (вряд ли это получится)?

Но самое главное, как правильно быть на уровне связи моделей с контроллерами? Контроллер должен обращаться к какому-то классу внутри Сервисов, а тот в свою очередь создавать необходимые объекты других классов из того же Сервиса, которые в свою очередь подтягивают Ларавелевские модели… или как? Какая-то длинная цепочка получается.
Про репозитории читал, и кажется, что это может помочь в данном вопросе, но до конца не пойму как именно? То, что в качестве хранилища может использоваться не только БД, но и что-то иное – это все здорово, конечно, но только я с таким особо не сталкивался, и мне кажется, что это избыточно – заботиться о том, что может случиться в одном случае из ста. Или я не прав, и их можно использовать не только для разделения способов хранения, но и для лучшей организации работы контроллера с моделью? Или это вообще не о том?

В общем буду рад, если поделитесь шаблонами Ваших наработок на Laravel, или дадите ссылку на опыт других разработчиков в данном вопросе.

Спасибо!
  • Вопрос задан
  • 2309 просмотров
Решения вопроса 1
@vism
Все просто, для логики - сервисы. да.
В моделях оставются всякие рилешены, мутаторы, я туда так же сую проверки простые, типо checkIsPaid()

Ничего страшного, что сервис знает о модели.
А данные в сервис пердавать желательно через DTO, также видел некоторые реквесты передают, но не массивом или списком агрументов.
Репозитарий обычно не нужен если используете элокуент. Репозитарий нужен как поддержка разных испочников данных. типо если у вас есть елокуент и докрин или вобще какое-то сторонее апи, то описывается интерфейс репозитария и уже для каждого источника реализуется по разному.
Если у вас только элокуент, то по сути репозитарий будет повторять вашу модель. вобщем шило на мыло. элокуент грубо говоря репозитарий для разных БД
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
- метод контролера один, но используется GET переменная «json», скажем. Добавляем блок if, если переменная присутствует, то отдаем json, иначе отдаем view. Но тоже, как-то не кошерно смотрится…
Это по тому что это должны быть разные контроллеры, один для вебморды, один для API/app.
Ответ написан
vfreelancer
@vfreelancer
php
может, это поможет
Ответ написан
Комментировать
Compolomus
@Compolomus
Комполом-быдлокодер
Я бы вам посоветовал не тормозить на одном ларавел, хотите красивый и аккуратный код с правильной структурой и принципами, гляньте в сторону зенд. В нем есть куча готового под все задачи кода, и он очень просто для расширения. Все что можно там имеет интерфейс, то есть нужен ответ в json, сделайте свою реализацию используя интерфейс, но скорее всего там уже есть подобная реализация.
Плюсы зенд., зенд ни чего не навязывает, не вью не модель, самое сложное это осилить конфиг, если смотреть в сторону зенд3, а лучше зенд-экспрессив, он более расширяемый
https://olegkrivtsov.github.io/using-zend-framewor...
Книжка по zf3 можно бегло пробежать, вы поймёте плюсы сами
https://github.com/zendframework/zend-expressive
Плюс пачка репов уже нужного кода (100+)
Ответ написан
@MeKree
По первому вопросу, желательно отделять контроллеры отвечающие за view и json. Т.е создаются 2 контролёра. Один возвращает view другой json.

По вопросу модели, здесь описан вариант реализации.

А вообще если смотреть на Java для сравнения, там есть паттерн DTO который упрощает жизнь
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы