Логика Laravel CMS для общих функций / полей
Я новичок в Laravel, поэтому мне сложно понять логику того, что по сути является CMS с несколькими типами контента.
Скажем, у меня есть 3 типа контента; Еда, книги и автомобили. Каждый элемент во всех типах контента имеет имя, URL-адрес и несколько других полей.
Я могу создавать, обновлять и удалять любой из этих ресурсов, скорее всего, один и тот же код будет реплицирован 3 раза. Единственная разница будет с созданием или обновлением, поскольку имена полей у них будут различаться.
Должен ли я просто дублировать эти поля / функции для каждого контроллера или создать что-то общее в одном месте?
Пересечение полей / функций изначально не будет огромным, однако это кажется неэффективным, скажем, если бы у меня было 10 типов контента, и я хочу добавить одно поле ко всем из них, мне нужно обновить код в большом количестве мест.
Если бы у меня был центральный «узел», который содержал идентификаторы и общие поля для ВСЕХ элементов в каждом типе контента, а затем связал бы его с отдельными таблицами для настраиваемых полей, я был бы в гораздо лучшем положении, когда хочу добавить, обновить или удалите общие поля.
В настоящее время у меня есть 3 контроллера, и пока я работал только над одним, поэтому у меня есть функции index(), show() и edit() в контроллере.
В качестве теста я создал модель узла с php artisan make:model Node -mcr и просто расширил существующие контроллеры, чтобы они расширяли NodeController. Который только что вызвал такую ошибку;
Declaration of App\Http\Controllers\FoodController::show(App\Food$food) should be compatible with App\Http\Controllers\NodeController::show(App\Node $node)
Скорее всего, это не способ сделать это в любом случае, но я просто не знаю рекомендуемой практики для этого.
Ответы 1
Наиболее подходящая и стандартная передовая практика для вашей проблемы:
иметь одну таблицу базы данных, скажем, имя таблицы как node, которое будет содержать все общие поля, и иметь другую таблицу как categories и связать ее с таблицей node (1-m) для классификации типа узла, такого как автомобиль, книга, еда и т.д., и создайте еще одну таблицу, скажем, node_meta, в которой будут храниться все дополнительные атрибуты в зависимости от типа узла,
(вы можете взглянуть на диаграмму ER базы данных WordPress CMS, которая имеет аналогичный дизайн db.)
Полиморфное отношение не является хорошей идеей для этого, как указано выше другим пользователем, оно имеет некоторые ограничения, когда дело доходит до запроса базовых данных, например, вы не можете применить запрос whereHas, и до сих пор нет официального решения для Эта проблема.
Обратите внимание, я нет проголосовал против. Я не вижу необходимости лично голосовать против. Я понимаю, что моя проблема - это не просто проблема Laravel, как вы говорите, это еще и дизайн базы данных. Это, конечно, не то или иное, поскольку я знаю, что мог бы предложить работоспособное решение на простом PHP, но, очевидно, я хочу, чтобы это решение хорошо работало с Laravel и Eloquent, поэтому я вручную получаю / устанавливаю данные без надобности.
Мне очень жаль винить вас, я не смог найти, кто проголосовал против, и побежал, не дав комментарий по причине голосования против, переполнение стека должно быть очень строгим в этом вопросе, так как мы тратим свое время на написание соответствующего ответа, и люди голосуют против и бегут без уважительной причины и просто для повышения своей репутации, это не совсем честно и заставляет меня закрывать свой аккаунт так ..
Хотя официального решения для использования whereHas с полиморфными моделями не существует, решения все же существуют: github.com/laravel/framework/issues/5429#issuecomment-268178 279
Я не знаю причину, по которой вы проголосовали против моего ответа, но очевидно, что ваши вопросы не связаны с Laravel, это в первую очередь о соответствующем дизайне базы данных, а затем у вас может быть один контроллер, чтобы избежать дублирования кодов, как бы вы ни показали мне ваша глупость опровергает мой ответ ..