Comments 5
Используем OData в своих проектах. Что тут можно сказать - это боль и страдания, когда пытаешься сделать шаг влево-вправо. В базовом сценарии работает неплохо, но чуть сложнее - и всё, лютые костыли повсюду.
Пример: вернуть по запросу для одной модели другие модели (например, если фильтр по пользователям, а вернуть надо посты этих пользователей) - через одату мы это сделать так и не смогли, потому что по концепции Микрософта какая сущность в запросе, такая и в ответе.
Куча странного с версионированием api. Например, для v1 нормально работает get/{id}, а для v2 работает только get/{key}, потому что key - конвенционное имя. Это справедливо для 7 версии по крайней мере
Боль миграции - мы до сих пор не можем переехать на последнюю версию пакетов, потому что то одно, то другое отваливается в непредсказуемых местах...
Кроме того, что odata - это почти прямой интерфейс к БД, при котором вся ответственность за оптимальность запросов (если отбросить другие негативные аспекты этого) переложена на клиента и магию EF. Подозреваю (сами не пробовали), что всякие самописные запросы или хранимые процедуры выставить через одату будет тем ещё квестом, особенно с учётом всяких select/expand-опций.
В общем, на наших проектах мы стремимся отказаться от неё настолько, насколько это возможно, и использовать по минимуму. Для меня лично вырисовываются следующие приемлемые кейсы:
прототип API или сервиса, когда надо быстро достать данные из БД, а клиент ещё сам не до конца понимает, какие данные нужны (обычно после этого написанный API выкидывается и пишется пачка нужных методов)
ненагруженный API, который тем не менее должен иметь некоторую вариативность. Тут проще выставить OData-метод и смириться с тем, что запрос будет генерировать клиент
OData подкупает своей кажущейся простотой и отсутствием необходимости писать 100500 разных методов API с разными возвращаемыми данными, но "вдолгую" всё равно оказывается необходимым эти самые методы написать и под них оптимизировать запросы
я не продаю ОДату, но хотел спросить насчёт постов пользователей… а почему вам $expand не помог? Ведь в рамках стандарта вы получаете список пользователей и раскрываете их посты.
Просто в случае если вам нужны только сообщения пользователей, вы же наверняка имеете связку от ребёнка к родителю, где теоретически фильтр должен будет сработать.
В худшем случае, вы всегда можете написать оптимизированную версию custom-действия — принять определенные параметры, вернуть другие значения.
expand не помог потому, что там нет прямой связи между сущностями. В данном конкретном примере требовалась дополнительная логика по выборке данных из базы.
А функция не взлетела по следующей причине (вероятно, я ввёл в заблуждение слишком кратким описанием примера) : нам надо было, чтобы опция filter работала по одной сущности (пользователь), а другие опции (select/expand) - уже по возвращаем ой коллекции постов. Вот в такое одата не смогла, пришлось подставлять костыли
Я в своих проектах одата использую для отчётности. Делается метариализованное представление, прописывается в качестве entity, интегрируется в Excel или power bi и можно забыть навсегда. Работает отлично.
Мой опыт работы с OData