Сейчас пытаюсь отдельный проектик написать с примера "Интернет-провайдер" и идей order_details тут получается что на каждый тип товара нужны разные столбцы деталей.
Попробую подробнее расписать:
Для деталей заказа Products понадобится: productId, count, attributeId, attributeValueId
Для деталей заказа Services понадобится: serviceId, dateRecieving (Дата предоставления услуги)
Для деталей заказа Tariffs (Тарифы пакетов интернета/TV): tariffId, dateStart(Дата начала услуги), dateEnd (Дата окончания услуги).
По такой логике получается мне нужно будет все таки сделать так:
order_products_details
order_services_details
order_tariffs_details ?
Ипатьев, В моем случае да.
Сейчас требуется все переделать под следующий пример - "Приложение интернет провайдера".
Там можно:
1. Купить оборудование Wifi роутер или TV приставка (Продукт);
2. Оплатить услугу сотрудника, который приедет к вам и подключит кабель к роутеру (Услуга);
3. Оплачивать ежемесячно тариф интернета (Услуга в виде тарифов).
Все эти пункты являются отдельными сущностями, которые оплачиваются, Фишка в том, что Вип-статус я покупаю отдельно, подписку оплачиваю тоже отдельно.
Ипатьев, можно. Просто таблица orders была напрямую связана с таблицей products. А сейчас кроме продуктов появились подписки в виде услуг такие как Вип-статус, которые нужно оплачивать отдельно. И создавать клон таблицы orders на service_orders, где заменится productId на serviceId кажется плохим решением.
Мда и этот чел мне что то про solid с ооп пытался внушить до сих пор кста свои слова не аргументировал. Надо было сразу чекнуть твой профиль и кинуть в игнор.
mkone112, ну значит ты слит раз не смог с 3-ей попытки аргументировать свои слова и наверное пишешь код в таком стиле: раз код не по ооп значит единая ответственность не распространяется, гений мыслей.
Особо ничего не изменилось, логика кода внутри метода будет точно таким же. Даже если я буду принимать данные/зависимости в конструкторе, мой метод остается неизменным, разве что в конструкторе я опять же буду вызывать модуль генераций хеша, тогда вопрос будет немного задан по другому: - "А правильно ли что в экземпляре класса я дергаю модуль генераций пароля?".
Поэтому мой вопрос был задан в простом формате вынести модуль генераций хеша пароля (из куска кода, который взаимодействует с пользователем) или нет aka Должен ли этот метод тогда только уметь обновлять данные тем самым получив в параметрах этот hash, а не самому создавать его.
У тебя есть другой ответ?
то есть лучше под разный маршрут создавать свой контроллер?
Для обновления аватара AvatarController? хм, по сути удобно я могу создать там методы как для загрузки автара самого пользователя так и для администратора. Верно?
PUT - /api/users/avatar (AvatarController.update) для обычных пользователей
PUT - /api/users/:id/avatar (AvatarController.updateById) для админов
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Попробую подробнее расписать:
Для деталей заказа Products понадобится: productId, count, attributeId, attributeValueId
Для деталей заказа Services понадобится: serviceId, dateRecieving (Дата предоставления услуги)
Для деталей заказа Tariffs (Тарифы пакетов интернета/TV): tariffId, dateStart(Дата начала услуги), dateEnd (Дата окончания услуги).
По такой логике получается мне нужно будет все таки сделать так:
order_products_details
order_services_details
order_tariffs_details ?