Какой вариант структуры файлов моделей в Laravel лучше?
Какой вариант структуры файлов моделей в Laravel лучше? Хочу сразу определиться на начальном этапе.
Вариант 1:
appModelsBlogPost.php
appModelsBlogCategory.php
appModelsBlogTag.php
appModelsShopOrder.php
appModelsShopProduct.php
Вариант 2:
appModelsBlogPost.php
appModelsBlogCategory.php
appModelsBlogTag.php
appModelsShopOrder.php
appModelsShopProduct.php
В 1 варианте автоматическое заполнение имени таблицы $table ломается, поэтому в каждой модели придется указывать вручную. Но зато вроде как более структурировано.
В 2 варианте автоимена работают. Но получается, что все в куче.
Как вариант более грамотен?
Дополнительно:
Для маленького проекта разницы нет. Можно использовать тот вариант, что быстрее.
Если хочется знать, есть ли архитектурный паттерн для группировки сущностей - то это DDD (Domain Driven Design). Судя по всему, можно выделать 2 агрегата - Shop и Blog.
Однако, до изучения темы, лучше выстраивать архитектуру на основе известных принципов программирования.
- Хм. Спасибо. Возьму на заметку. Но мои модули будут не на столько велики, чтобы их отделять в домены. Blog и Shop это для примера. По сути, только модели и ресурсы нужно будет поделить на подкаталоги. А так паттерн интересный.
- CaptainJustness,
По сути, только модели и ресурсы нужно будет поделить на подкаталоги
Только если бизнес оперирует словами "модели" и "ресурсы", ведь DDD - это про единый язык между разработчиками и бизнесом.
Ответы:
appModelsPost.php
appModelsCategory.php
appModelsTag.php
appModelsOrder.php
appModelsProduct.php
И учиться проектировать базу данных без кучи мусора вроде OrderTag PostTag и тд
Имхо: через какое-то время будешь туда только заглядывать чтобы вспомнить что-нить а если не лениться писать комментарии (ну и плагины ide всякие для удобства) то и вообще не будешь.
Имхо2: в модули не сильно запаривайся - хлебнешь лишнего головняка. Рано или поздно для своего же удобства начнешь выносить часть функционала и найдешь свой путь.
Лучше первый :) Особенно если проект большой и будет много моделей.
Руками прописать свойство $table в модель это дело одной минуты.
- Да, моделей будет много, поэтому и решил разделить на каталоги.
По поводу прописать руками. Я думаю сделать класс appModelsModel.php и в нем переназначить метод getTable() с добавлением генерации имени таблицы с учетом каталога, затем указать его в моих моделях.
Как думаете, этот вариант будет лучше чем прописать вручную? Или вручную лучше?
- CaptainJustness, норм. если нужно будет переназначить - уже в конечной модели исправите.
- CaptainJustness, излишнее наследование, лучше изменить stub создаваемой модели, или хотя-бы использовать trait.
- Виктор, Спасибо. Получается stub изменить, чтобы $table прописывалась автоматом, либо trait юзать, чтобы не делать наследование. А где в Laravel хранить trait?
- CaptainJustness, если названия будут стандартизированны, то точно быстрее ) тут много разных вариантов есть... как тебе выше предлагали стаб поменять или трейт добавить. Но по времени что вставка трейте, что вставка $table одинаково, так что нет смысла менять шило на мыло.
- CaptainJustness, данный trait, где-то в технической директории (где хранят "хелперы", надстройки над компонентами и т.п.). Так называемый, инфраструктурный слой.
- Виктор, А что плохого в излишнем наследование в данном случае?
Почему не смущает, что все контроллеры наследуются от одного общего Controller в папке проекта?
- YepBro, как правило, туда со временем добавится еще функционал, а потом придется городить костыли из-за необходимости разного поведения. Это просто совет, использовать что-то более гибкое и узконаправленное.
Почему не смущает, что все контроллеры наследуются от одного общего Controller в папке проекта?
Речь об этом не шла. И где написано, что "не смущает"? Просто паттерн такой (Input Controller назвается), исторически сложилось.
Вариант 3.
Не валить в app вообще.
Создать свою папку под свои классы - MyCompany.
В ней программировать модули раздельно (предполагая, что они в таком виде, возможно, пойдут и в другие проекты):
MyCompanyBlogModelsPost.php
MyCompanyShopModelsOrder.php
Кстати, и в БД потом таблицы смотреть куда проще, когда мухи с котлетами не перемешаны.
Если проект большой, я бы вообще предпочел разделение по группам ответственности.
Для ларки есть отличный пакет для этого – nwidart/larabel-modules
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
В Laravel, структура файлов моделей может быть организована по-разному в зависимости от конкретных потребностей проекта. Однако, есть несколько распространенных вариантов, которые могут быть рассмотрены.
1. Одиночный файл на каждую модель:
В этом варианте каждая модель располагается в отдельном файле. Например, если у вас есть модель User, то файл будет называться User.php. Этот подход хорошо подходит для небольших проектов, где количество моделей невелико.
app/ User.php
2. Группировка моделей в каталоги:
Другой вариант - группировка моделей по определенным категориям или функциональности в каталоги. Например, все модели, относящиеся к административной части сайта, могут быть помещены в каталог Admin.
app/ Models/ Admin/ User.php
3. Разделение моделей по слоям:
Также можно разделить модели по слоям, например, создав каталоги для моделей, отвечающих за работу с базой данных, бизнес-логикой и представлением.
app/ Models/ Database/ User.php Business/ UserRepository.php Presentation/ UserPresenter.php
4. Использование дополнительных пакетов или структур:
Некоторые разработчики предпочитают использовать сторонние пакеты или структуры для управления моделями, такие как Repository Pattern или Service Pattern. В этом случае файлы моделей могут быть организованы соответственно.
Выбор структуры файлов моделей в Laravel зависит от конкретных потребностей проекта и предпочтений разработчика. Главное, чтобы структура была легко читаемой, поддерживаемой и соответствовала принципам разделения ответственности и модульности.