Нужна помощь Планирование архитектуры для категоризации Connundrum
У меня больше вопрос "что бы ты сделал", чем вопрос о кодировании. Это относится к проекту, над которым я сейчас работаю. В этом проекте перед нами стоит задача объединить несколько рыночных API в один интерфейс. Каждый API имеет свой уникальный способ категоризации продуктов. Родительские категории верхнего уровня для всех API, на которые мы смотрим, более или менее одинаковы с некоторыми вариациями. Но подкатегории сильно отличаются.
Например, для одного API требуются длинные трассы для выбора категории, такие как: Спорт> Спорт с мячом> Новая Англия> Футбол> Активные команды> Патриоты> Памятные вещи. В то время как другой API имеет двухуровневую категоризацию: Спорт> Патриоты Памятные. Во многих случаях существуют подкатегории, которые вообще не связаны с подкатегориями других API.
Итак, вопрос в том, что лучше всего использовать при разработке интерфейса? В настоящее время мы боремся между двумя возможностями:
1) Создайте пользовательский пользовательский интерфейс категории на клиенте, а затем встроите логику в сервер, который сможет сортировать потребности различных API на основе выбранных пользователем вариантов.
2) Создайте пользовательский интерфейс таким образом, чтобы пользователь проходил необходимые шаги для каждого отдельного API. В зависимости от настроек пользователя это означает, что ему может потребоваться заполнить API - специфическую информацию 5,6,10 или более раз.
Хотя мне говорят, что вариант номер один - настоящий кошмар программирования (пример, который я привел, это изменение полей данных API), я твердо убежден, что вариант номер два разозлит клиентов.
Любые идеи там?
3 ответа
Номер один не так уж страшен из кошмара. Опыт ваших пользователей является приоритетом номер один; никогда этого не забывай. Если пользователю легче перемещаться по более короткому маршруту, предоставьте ему такую возможность. Кроме того, я бы обернул API некоторой абстракцией, чтобы мой код вообще не знал об API и знал только об уровне абстракции. Таким образом, я могу изменить API и оставить большую часть своего кода в покое, изменив только уровень абстракции.
Используйте сеанс для передачи данных со страницы на страницу и фабрику для создания состояния страницы при вводе на основе данных сеанса; это усилит контекст между страницей, состоянием и пользовательскими данными.
Держите объекты первого уровня (те, с которыми непосредственно общается страница) в контексте со страницей; это поможет при диагностике проблем.
Самое главное, создайте серию тестов для вашего уровня абстракции, которые проверяют каждый объект, функцию и пару входных и выходных данных, чтобы убедиться, что ваше приложение надежно.
Это очень сложная проблема. Если вы ищете "классификация продукции онтологий", вы найдете много научных статей и дискуссий по этой теме. Если бы один был просто более подробным вариантом другого, это было бы вполне осуществимо, но ваше описание подразумевает, что это не так, и, следовательно, вам нужно будет построить свою собственную схему классификации и отобразить на ней другие.
У вас есть общий ключ (код UPC? Или другой), который позволит вам проверить соответствие между различными категориями продуктов? Если это так, вы можете построить свою собственную схему категоризации, а затем с некоторой долей успеха отобразить на ней другие.
Очевидно, что первый вариант является наилучшим для потребителя, но создание такого отображения может быть очень трудным и очень трудоемким, и для него потребуются постоянные обновления.
Один из подходов заключается в создании более простой иерархии, чем любой из предложенных. Более простая иерархия значительно облегчит [в основном ручное] отображение категорий в вашу иерархию, поскольку большинство из них просто будут включениями. Это может ухудшить взаимодействие с пользователем, но если вы добавите отличные возможности поиска и отличные "сопутствующие товары" / "люди, купившие это, также купят эти" инструменты для просмотра товаров, вы, вероятно, сможете восполнить отсутствие иерархии.
Вы должны предоставить своим клиентам последовательный неизменяемый интерфейс.
Я хотел бы увидеть пример двух разных подходов, которые вы имеете в виду.
API.find( PRODUCT, CATEGORIES_LIST )