Какой вариант структуры файлов моделей в Laravel лучше?

Question

[CaptainJustness]

Какой вариант структуры файлов моделей в Laravel лучше? Хочу сразу определиться на начальном этапе.

Вариант 1:
app\Models\Blog\Post.php
app\Models\Blog\Category.php
app\Models\Blog\Tag.php
app\Models\Shop\Order.php
app\Models\Shop\Product.php

Вариант 2:
app\Models\BlogPost.php
app\Models\BlogCategory.php
app\Models\BlogTag.php
app\Models\ShopOrder.php
app\Models\ShopProduct.php

В 1 варианте автоматическое заполнение имени таблицы $table ломается, поэтому в каждой модели придется указывать вручную. Но зато вроде как более структурировано.
В 2 варианте автоимена работают. Но получается, что все в куче.

Как вариант более грамотен?

Answer 1

[Виктор]

Для маленького проекта разницы нет. Можно использовать тот вариант, что быстрее.

Если хочется знать, есть ли архитектурный паттерн для группировки сущностей - то это DDD (Domain Driven Design). Судя по всему, можно выделать 2 агрегата - Shop и Blog.

Однако, до изучения темы, лучше выстраивать архитектуру на основе известных принципов программирования.

Comments

[CaptainJustness]

Хм. Спасибо. Возьму на заметку. Но мои модули будут не на столько велики, чтобы их отделять в домены. Blog и Shop это для примера. По сути, только модели и ресурсы нужно будет поделить на подкаталоги. А так паттерн интересный.

[Виктор]

CaptainJustness,

По сути, только модели и ресурсы нужно будет поделить на подкаталоги

Только если бизнес оперирует словами "модели" и "ресурсы", ведь DDD - это про единый язык между разработчиками и бизнесом.

Answer 2

[pLavrenov]

app\Models\Post.php
app\Models\Category.php
app\Models\Tag.php
app\Models\Order.php
app\Models\Product.php

И учиться проектировать базу данных без кучи мусора вроде OrderTag PostTag и тд

Имхо: через какое-то время будешь туда только заглядывать чтобы вспомнить что-нить а если не лениться писать комментарии (ну и плагины ide всякие для удобства) то и вообще не будешь.
Имхо2: в модули не сильно запаривайся - хлебнешь лишнего головняка. Рано или поздно для своего же удобства начнешь выносить часть функционала и найдешь свой путь.

Answer 3

[YepBro]

Лучше первый :) Особенно если проект большой и будет много моделей.

Руками прописать свойство $table в модель это дело одной минуты.

Comments

[CaptainJustness]

Да, моделей будет много, поэтому и решил разделить на каталоги.

По поводу прописать руками. Я думаю сделать класс app\Models\Model.php и в нем переназначить метод getTable() с добавлением генерации имени таблицы с учетом каталога, затем указать его в моих моделях.

Как думаете, этот вариант будет лучше чем прописать вручную? Или вручную лучше?

[Dmitry Bay]

CaptainJustness, норм. если нужно будет переназначить - уже в конечной модели исправите.

[Виктор]

CaptainJustness, излишнее наследование, лучше изменить stub создаваемой модели, или хотя-бы использовать trait.

[CaptainJustness]

Виктор, Спасибо. Получается stub изменить, чтобы $table прописывалась автоматом, либо trait юзать, чтобы не делать наследование. А где в Laravel хранить trait?

[YepBro]

CaptainJustness, если названия будут стандартизированны, то точно быстрее ) тут много разных вариантов есть... как тебе выше предлагали стаб поменять или трейт добавить. Но по времени что вставка трейте, что вставка $table одинаково, так что нет смысла менять шило на мыло.

[Виктор]

CaptainJustness, данный trait, где-то в технической директории (где хранят "хелперы", надстройки над компонентами и т.п.). Так называемый, инфраструктурный слой.

[YepBro]

Виктор, А что плохого в излишнем наследование в данном случае?

Почему не смущает, что все контроллеры наследуются от одного общего Controller в папке проекта?

[Виктор]

YepBro, как правило, туда со временем добавится еще функционал, а потом придется городить костыли из-за необходимости разного поведения. Это просто совет, использовать что-то более гибкое и узконаправленное.

Почему не смущает, что все контроллеры наследуются от одного общего Controller в папке проекта?

Речь об этом не шла. И где написано, что "не смущает"? Просто паттерн такой (Input Controller назвается), исторически сложилось.

Answer 4

[Adamos]

Вариант 3.
Не валить в app вообще.
Создать свою папку под свои классы - MyCompany.
В ней программировать модули раздельно (предполагая, что они в таком виде, возможно, пойдут и в другие проекты):
MyCompany\Blog\Models\Post.php
MyCompany\Shop\Models\Order.php
Кстати, и в БД потом таблицы смотреть куда проще, когда мухи с котлетами не перемешаны.

Answer 5

[Сергей delphinpro]

Если проект большой, я бы вообще предпочел разделение по группам ответственности.
Для ларки есть отличный пакет для этого – nwidart/larabel-modules