Comments 4
Насколько я понял из статьи, хотя это не было выделено явно, FOR == filter+options+response. Вопросы:
К чему относятся права пользователя? Где здесь лежит авторизация?
Почему рассматривается только запрос поиска? Если пользователь создает продукт, куда лягут данные? в options?
Как быть когда представление данных отличается от того как они хранятся?
Как быть когда мы поверх одних данных и логики делаем как веб страницы, так и некоторое API, (например, для мобильных устройств)?
Общую мысль я не вполне уловил, речь идет об описании API сервера (вспомнился GraphQL) или об архитектуре самого сервиса?
Это концепция поиска данных, авторизация лежит выше.
примерно: route -> controller -> DataProvider -> models -> DB
на фронте вместо того чтобы сразу идти на бек (axios.get) - мы также реализуем поэтапно: DP->apiClass->Back Api
мне всегда не хватало стандартных моделей, потому мы пришли к этому.
Как быть когда представление данных отличается от того как они хранятся?
-> у нас мы в Response указываем те хендлеры , которые надо применить к ответу, все DataHandlers - чистое функциональное программирование. Есть схема входящих данных, есть схема выходящих
Почему рассматривается только запрос поиска?
Эта часть цикла - только про поиск. Сохранение будет рассмотрено дальше, это тоже большой пласт подходов
"Как быть когда мы поверх одних данных и логики делаем как веб страницы, так и некоторое API, (например, для мобильных устройств)?"
а это я не понял
Data Provider имеет 2 механизма работы:
Что за DataProvider? Вы сразу начинаете описывать механизмы, но не рассказали, что это
Также мы тут добавляем некий массив примитивных операций со статичным интерфейсом, когда фильтры избыточны, их может быть достаточно много и они также могут скрывать внутри себя фильтры, обеспечивая единообразие и одновременно упрощенный синтаксис)
Выглядит так, будто это разные уровни. Условно, примитивные операции являются более высокоуровневыми по сравнению с 'универсальным' методом поиска и должны бы вынесены в отдельный сервис, который уже сформирует нужный фильтр
Options - определяет область поиска (все что не filter и не response)
Непонятно от слова совсем. И примеров нет, что может быть в options
Есть ли возможность объединить фильтры через ИЛИ?
Кстати, почему методы статичные?
вы в любой момент без изменения бизнес логики сможете отказаться от реализации (которая в примере) и заменить её на более оптимизированный код (или даже отдельный сервис)
Непонятно, как я смогу изменить что то, если у меня на статику завязка)
Да, извиняюсь за неглубокое повествование и уход сразу в детали.
Что за DataProvider? Вы сразу начинаете описывать механизмы, но не рассказали, что это
DataProvider - это отдельный слой приложения. Он находится внутри. Его назначение - это получение всех данных. Внутри него вы уже реализуете кеширование, логирование и прочее. Разработчикам мы оставляем простой метод для получения данных.
Как сказано выше у него 2 метода. Первый универсальный, второй - массив простых действий, чтобы не писать каждый раз конструкцию options = {...} (исключение для простоты и сокращения кода. Второй - всегда использует первый.
Options - Непонятно от слова совсем
В не релизном состоянии, когда код все ещё пишется и нет абсолютно точного описания задачи и конечной цели, когда не проработана вся комбинаторика - есть кейсы, когда в запрос надо добавить некие опции, чтобы получить результат (назовем это прототипный код, к примеру). Это место, куда вы можете пихать, пока не поймете как с этим быть
Есть ли возможность объединить фильтры через ИЛИ?
В концепции нет никаких препятствий, в реализации, что приложено такое пока не заложено
Кстати, почему методы статичные?
Исключительно внутреннее соглашение, для единообразия и некое сокращения количества кода
Непонятно, как я смогу изменить что то, если у меня на статику завязка)
Рассматриваем модульное (микросервисное приложение) на php:
вы его написали, все хорошо. но в какой-то момент оно дало рост и получение и обработка данных стала давать не ту скорость, которая вас устраивает
можно переписать все на go - но это будет жутко дорого. вместо этого вы можете переписать внутренности DP на более высоко оптимизированном языке или любым иным способом
Второй кейс: у вас react/vue.
Есть некий компонент (форма создания какой-то элемента)
Поля формы сильно отличаются от контекста и типа этого элемента (к примеры товары в магазине)
Программист в начале имел всего 3 типа и всё было хорошо. Он за каждым ходит на бек, прямо внутри всего чудного компонента
В данном кейсе - нам надо будет переписать и компонент тоже, когда мы захотим его оптимизировать, к примеру, добавив некий TTL-кеш
Если бы он сразу написал FromProvider.get({type:any}) - тогда мы бы оптимизировали 1 участок (ядро системы), а не сотни вызовов axios.get()
Работа с данными. FOR-архитектура, часть 1