Архитектурный вопрос по Web API. Как правильно расшарить token между инстансами?
Приветствую.
Опыта у меня совсем немного в данных вопросах, поэтому решил обратиться к знающим людям, чтобы потом не было мучительно больно. Пишу скромный клиент под WP для одного сайта с использованием самописного API. Начинал все с чернового варианта, но потом пошло-поехало и он разросся до неудобоваримых рамеров. В данный момент для пользования API, я создаю 1 глобальный инстанс класса этого API, аутифицируюсь через него и он хранит в себе token. Затем просто дергаю методы этого инстанса, например:
myapi.LikeRecord(Record rec);
Соответсвенно, метод внутри хватает token и на выхлопе просходит LikeCompleted.
Мне же бы хотелось, чтобы для меня это выглядело несколько иначе: хочу сделать Record более независимым и использовать вот так
Recrod.Like();
но как правильно организовать шаринг token в данном случае? На ум приходит только какой нибудь статический класс, но вдруг это не верное направление?
Подскажите хотя бы в каком направлении мне копать.
Спасибо большое!
Оставьте как есть. Record.Like() -- явное нарушение SRP. Плюс, лишняя головная боль по поводу "как же мне создать объект класса Record" -- а там и до фабрик с декораторами и прочего энтерпрайза недалеко.
Record в теории может и сам себя создать, например по ID записи или URL, но опять же вопрос в tokenе. Мне мой текущий API не нравится своей псевдоасинхронностью. То есть если пользователь быстро вызовет Like для разных записей, то значит в Completed я должен буду передать и сам Record, чтобы понять к чему он относится (но я сделал иначе - меняю у Record свойство IsLiked, которое нотифайбл, хотя уверен, что это не правильно)
@carbon88 да. Либо напрямую запустил post запрос, либо дернул метод like для данной Record из некой сущности, но чтобы снаружи это выглядело для меня как тупо Record.Like(). Это сильно упрощенный пример, есть у меня еще объект Feed в планах. Сейчас это тупо список, который дергается 2 разными функциями и с горем-пополам мержится. Я бы хотел сделать Feed как самостоятельный Enumerable, что бы при итерации он сам занимался подгрузкой и объединением.
первый вариант это не правильно однозначно, в этом случае Record будет действительно разделять несколько ответственностей - представление этой самой записи и еще и общение с сайтом.
должен быть некий сервис или провайдер, который предостовляет доступ к апи сайта, и через который идет все взаимодействие. Record не должен знать о том как это все внутри этого сервиса происходит. он не должен знать о токенах, формате post-запроса и прочее. в свою очередь сервис должен знать что каждый объект, который ему передали в тот или иной метод имеет некий набор свойств и методов, необходимых в контексте этого метода.
@carbon88 хорошо, но как правильно поместить этот сервис внутрь Record? Если этот сервис будет в единственном экземпляре, то как в данном правильно словить нужный респонс от сервиса?
@carbon88 it depends.. в данном конкретном случае да. однако в других ситуациях я ловлю респонс (не обязательно относящийся к Record) во VM, чтобы освободить ее (перед колом выставяю IsBusy, который привязан к прогресс бару и используется в *CanExecute() для комманд, а при получении респонса освобождаю IsBusy) а быть может это не столько важно? Сейчас используется механизм call/event. Если я решусь его переписать, то скорее всего с использованием async/await и эта проблема должна отпасть, верно? Просто я много горя хлебнул с глобальным объектом и приаттачеными (и забытыми отаттачить) обработчиками его эвентов, стреляющими то тут, то там.. поэтому и решил все переписать, используя более независимые сущности.
