Задать вопрос

Правильная архитектура задачи под Laravel?

Добрый день, делаю небольшую систему умного дома на laravel, таким образом знакомлюсь с фреймворком и orm.
Есть задача вносить в базу данных датчики и устройства, они делятся на 3 типа:
1. реле - их можно только включить и выключить
2. датчики температуры, влажности и остальные которые возвращают значения, для них необходимо заложить возможность установки таймера, по которому будет произведен опрос
3. датчики моментального действия, к примеру движения, им необходимо заложить особое свойство, которое будет говорить что датчик без таймера

И встает вопрос как грамотно спроектировать такую связку, колхозным классическим методом представляю, а как всё это вложить в парадигму laravel не понимаю.

Сейчас есть понимание что нужно создать 3 модели:
1. Units - общая таблица всех возможных датчиков
2. UnitProperties - свойства этих датчиков (таймер, моментальный опрос, включить выключить)
3. DeviceUnits - соотношение платы умного дома и непосредственно уникального датчика

Получается ещё нужна модель где будут описаны взаимоотношения DeviceUnit и UnitProperties или нет? Как соотнести в конце функционал отдельный каждого датчика и непосредственно поведение датчика на плате.
  • Вопрос задан
  • 1022 просмотра
Подписаться 5 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 1
Dase23
@Dase23
back-end developer
Модель для связи не нужна.
Связь создается уже внутри моделей с помощью методов
BelongTo
HasOne
HasMany
итд


И все таки мне кажется удобнее было бы под каждый датчик завести свой контроллер и свою модель.
Так как они выполняют достаточно разные функции и значения у них тоже разные. Если мы пытаемся термометр у которого значение одно и в градусах, связать в единой таблице с датчиком ИК движения у которого свойств может быть уже 5 и естественно в совершенно других значениях. Что вынуждает нас либо нарушать все возможные НФ, либо плодить кучу связных таблиц. или же еще хуже использовать модель EAV


В общем я вижу ситуацию так
  • Мы знаем все о наших датчиках и платах поэтому можно не пытаться делать их универсальными гораздо проще будет работать с датчиком как с конкретным элементом это будет и приятнее и более функционально и меньше геморроя вы попытках все делать универсальным помните про KISS


  • думаю что вряд-ли в системе будут датчики и платы добавляться каждый день -> ничто не мешает считать каждый датчик за отдельную сущность с его параметрами и функциями


  • в этих же контроллерах модели в бд храним поведение датчика на плате опять все просто и легко



в конце концов SQL хорош когда нам нужна целостность данных) а тут можно вообще все в паре ключ значение запихать в REDIS и не париться вообще + работать будет быстрее)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы