Фильтрация с помощью веб-API - PullRequest
3 голосов
/ 13 марта 2019

У меня есть приложение с несколькими контроллерами Web API, и теперь у меня есть требование, позволяющее фильтровать результаты GET по свойствам объекта.Я пытался использовать OData , но не уверен, подходит ли он по нескольким причинам:

  1. Контроллер Web API не имеет прямого доступа кDataContext, вместо этого он получает данные из нашей базы данных через слой «домен», поэтому он не имеет представления о наших моделях Entity Framework.
  2. Привязывая к первому элементу, веб-API работает с облегченными объектами модели DTO, которыепроизводятся на уровне домена.Это то, что скрывает модели EF.Проблема в том, что я хочу, чтобы эти запросы выполнялись в нашей базе данных, но к тому времени, когда метод Web API получает коллекцию со слоя домена, все объекты в коллекции были сопоставлены с этими объектами DTO, поэтому я не вижукак фильтр OData может выполнять свою работу, когда объекты когда-то удаляются из EF таким образом.
  3. Этот элемент может быть самым важным: мы не хотим разрешать произвольные запросы к нашей сети.API / базы данных.Мы просто хотим использовать эту библиотеку OData, чтобы избежать написания наших собственных фильтров, и фильтровать парсеры / компоновщики для каждого типа объектов, которые могут быть возвращены одной из наших конечных точек Web API.

Я не на том пути, основываясь на № 3?Если нет, сможем ли мы использовать эту библиотеку OData без значительного рефакторинга того, как взаимодействуют наш Web API и EF?

1 Ответ

1 голос
/ 14 марта 2019

У меня не было опыта работы с OData, но, насколько я вижу, он предназначен для подпитки контекста и управляет взаимодействием и возвратом этих моделей.Я определенно не фанат возврата сущностей в любой форме клиенту.

Это ужасная ситуация, но когда я сталкиваюсь с этим, мой первый путь действий - отодвинуть клиентов, чтобы оправдать их потребности в поиске.Запрос по умолчанию почти всегда: «Хорошо, было бы неплохо иметь возможность поиска по всему».Мой ответ на этот вопрос заключается в том, что я не хочу знать, что вы хотите, я хочу знать, что вам нужно, потому что я не хочу давать вам заряженное ружье, чтобы отстреливать себе ногу, а затем заставлять вас винить меня, потому чтосистема остановилась.Поиск является огромным фактором снижения производительности, если он слишком открыт.Трудно проверить точность / релевантность и эффективно проиндексировать 100% возможных случаев поиска, когда пользователям требуется только * 25% этих сценариев.Если клиент не может сказать вам, в каком поиске он будет нуждаться, и просто хочет все, потому что ему может это нужно, тогда ему это пока не нужно.

Лично я придерживаюсь определенных поисковых DTOи перевести их в выражения linq.

Если бы я столкнулся с жестким требованием реализовать что-то подобное, я бы:

  1. Попытался бы заставить эти поиски / отчеты бытьсделано от реплики отчетности, которая синхронизируется с действующей базой данных.(Чтобы свести к минимуму кровотечение, когда некоторые менеджеры-идиоты запускают некоторые дурацкие неиндексированные критерии поиска, чтобы он не связывал производственную БД, где люди пытаются выполнять работу.)
  2. Создание нового ограниченного специфичного для DbContextдля поиска с отдельными определениями сущностей, которые предоставляют только минимальное количество свойств для представления критериев поиска и идентификаторов.
  3. Подключите этот ограниченный контекст к API и OData.Он вернет «результаты поиска».Когда пользователь выбирает результаты поиска, используйте идентификаторы (ID) для API, чтобы загрузить соответствующий домен, или инициируйте действие и т. Д.

нет.1. Необязательно, приятно, если они могут жить с поиском, не «видя» обновленных критериев, пока не будет воспроизведен.(То есть от нескольких секунд до минут в зависимости от стратегии / размера репликации) Обычно эти поиски используются для запросов типа отчетов, поэтому я бы старался отделить их от обычных вариантов повседневного поиска, которые используют пользователи.(Т.е. опция расширенного поиска или тому подобное.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...