Иерархия моделей в Laravel?

Question

[Ёж Туманный]

Доброго времени суток, %username%!

Смотри какая штука. Ответ на вопрос, описанный ниже, наверняка лежит на поверхности, но что-то никак не удается его сформулировать.

У нас есть абстрактная фабрика, которая выпускает продукцию. Абсолютно вся продукция обладает таким свойством как артикул. Кроме того, вся продукция делится на два класса:

• Двери
  
  1. Тип: Двери межкомнатные (свойства: материал, ширина, высота, цвет)
     
  2. Тип: Двери входные (свойства: материал, ширина, высота, огнеупорность)
     
  
  
  
• Окна
  
  1. Тип: Окна пластиковые (свойства: материал, ширина, высота, цвет)
     
  2. Тип: Окна деревянные (свойства: материал, ширина, высота, покрыты ли лаком)
     
  
  
  

Для того, чтоб описать данные взаимоотношения в Laravel мы можем создать одну миграцию таблицы product, описать у неё все возможные свойства, что упоминаются в типах (класс, тип, артикул, ширина, высота, материал, огнеупорное ли, покрыты ли лаком), после чего создавать модели необходимых изделий, сохраняя требуемое нам наследование, но тут вопрос - как, например, указать для модели, при работе с общей таблицей (где хранятся вообще все продукты) возвращать только те, у которых указан, например, класс = (int) 2?
Более того, если мне необходимо вернуть все окна - я хочу просто дернуть модель /App/Models/Products/Doors и получить коллекцию вообще всех дверей, а если дерну /App/Models/Products/Doors/Interior - то только межкомнатные двери.

В общем - как лучше в таком случае организовать eloquent? Для каждого изделия создавать свою таблицу, но как тогда включать её во все "родительские" модели?
Или если всю продукцию хранить в одной, а при добавлении нового изделия (с новым свойством, к примеру) - просто писать миграцию на добавление поля? Но как тогда заставить "родительские" модели возвращать свеже-добавленные, а конкретную модель добавленного изделия - только её?
Или лучше ключевые свойства, такие как класс и тип вынести в отдельные таблицы, и связать их hasMany/hasOne?

Подскажите, пожалуйста.

Answer 1

[Finsh]

Для того, чтоб описать данные взаимоотношения в Laravel мы можем создать одну миграцию таблицы product, описать у неё все возможные свойства, что упоминаются в типах (класс, тип, артикул, ширина, высота, материал, огнеупорное ли, покрыты ли лаком), после чего создавать модели необходимых изделий, сохраняя требуемое нам наследование, но тут вопрос - как, например, указать для модели, при работе с общей таблицей (где хранятся вообще все продукты) возвращать только те, у которых указан, например, класс = (int) 2?

Вы Собираетесь хранить довольно много лишних, пустых ячеек и создавать вагон ненужных моделей. Не делайте так. Продукты делятся не на 2 класса, а на 2 типа. А тип(Окна пластиковые, Окна деревянные) - это одно из свойств продукта(материал).

1. Одна таблица для продуктов, где храните артикул и обязательные поля для всех продуктов.
2. Одна таблица для свойств продуктов, где храните все свойства для продуктов.
3. Связь многие ко многим расскажет к какому продукту какое свойство относится. Это позволит гибко добавлять свойства и прикреплять их к продуктам без вмешательства программиста.
4. Одна таблица - одна модель. Можно заморочится и с ДМ и с репозиториями и т.д. но если по простому, то одна таблица - одна модель. Свзяывайте их реляциями.

Answer 2

[Кирилл Несмеянов]

Думаю стоит адаптировать ECS паттерн, а конкретнее Entity + Component. Думаю, идеально подойдёт.

P.S. Изначально он разработан для геймдева, где есть лучник, лучник-маг, лучник-маг-с-копьём и т.д. При этом без ограничений на характеристики и их связи.