Как структурировать Laravel приложение?

Question

[maxandush9494]

Занимаюсь изучением Laravel 6, для написания своего приложения.
В связи с этим у меня возникло несколько вопросов, касающиеся структурирования проекта:
1) В документации повсеместно приводятся примеры, где контроллер напрямую обращается к Eloquent модели, что бы получить данные и передать во View. У меня возникло подозрение, что в реальных проектах существует еще один слой между, контроллером и моделью. Например, если у нас блог, и что бы получить какую-то публикацию, можно обращаться с какому-то классу, типа Posts:get($id) и уже там определять способ получения публикации, например, обращаться к Eloquent модели. Можно ли так делать? Имеется ли у Laravel какие-то указания по поводу этого? Ведь стоит только изменить имя поля, таблицы в базе данных и придется переписывать кучу файлов, а если использовать какой-то один класс для этого, то только в одном месте.
2) Модели так и должны все быть в папке app, или для них нужно создать отдельную директорию?
3) Где лучше размещать свои классы и функции? В документации, в качестве примера иногда используется импорт вроде use App\Services\... Но папки Services нет в разделе документации Directory Structure

Comments

[Максим Федоров]

В документации, в качестве примера иногда используется импорт вроде use App\Services\... Но папки Services нет в разделе документации Directory Structure

Cmd + N -> New Directory (Services)

Answer 1

[Alex Wells]

Как хотите. Главная проблема - заблуждение о том, что laravel дает готовую структуру которой надо свято следовать - а все как раз наоборот. Он из коробки дает возможность строить структуру так, как вам хочется, без каких либо последствий.

Я всегда сразу же разбиваю приложение на модули (домены) и там отталкиваюсь от нужной мне структуры.

Слепо переносить код из контроллера в сервис не имеет смысла, имхо.

Answer 2

[zorca]

1. Да. Зовется Repository - дополнительный слой абстракции, не зависящий от конкретного метода хранения данных.
   
2. Лучше создать новую директорию, это немного удобнее, чем кидать все модели в корень.
   
3. Для создания своего функционала, который достаточно объемен, по идеологии Laravel, требуется создавать Service Provider.
   

В целом пример хороших практик структуризации проекта можно подсмотреть в Laravel Boilerplate.

Comments

[Alex Wells]

1 - точно нет. Репозитории не нужны для маленько-средних проектов. Совсем. А когда будут нужны, то это говнище, на которое вы скинули ссылку, никак не поможет. Это вообще не репозиторий - это тупо query builder, написанный человеком, который дупля не бьет зачем ему этот репозиторий.

Не надо так делать. Хотите репозитории - пишите нормальные репозитории-синглтоны с системой критериев, от всего остального будут только проблемы.

[zorca]

Alex Wells, приведите пример тру-репозитория. Желательно код, слова ничего не стоят в мире программирования.

[Alex Wells]

zorca, NDA. Я не использую репозитории в фриланс и собственных проектах ибо там в этом никогда нет нужды.

Могу показать только контракт, дока вырезана:

interface Repository
{
  public function first(Criteria $criteria);
  public function firstOrFail(Criteria $criteria);
  public function paginate(?Criteria $criteria, ?int $perPage): LengthAwarePaginator;
  public function get(?Criteria $criteria = null): Collection;
  public function count(?Criteria $criteria = null): int;
  public function save($entities): void;
  public function delete($entitiesOrCriteria): void;
}