. NET CORE MVC - Generi c решение для фильтрации разных таблиц - PullRequest
Новая
       69

. NET CORE MVC - Generi c решение для фильтрации разных таблиц

1 голос
/ 23 апреля 2020

В настоящее время я разрабатываю сложную систему управления в. Net Core 2.2 MVC с множеством различных таблиц. Каждая таблица должна иметь возможность фильтров, сортировки и нумерации страниц.

Каждая таблица имеет отдельный объект базы данных и не имеет сходства с другими таблицами.

Существует ли способ генерации общего решение с использованием OData или Entity Framework или другой платформы без необходимости внедрять каждый файлер, сортировку или нумерацию страниц в каждом отдельном случае? Это должно быть обобщенное решение c, которое может быть аннотировано для методов действия контроллера для включения фильтрации и т. Д.

Фильтр должен выполняться сервером, а не с помощью javascript.

Я благодарю вас за ваше мнение и предложения. Приложены две фотографии затронутых таблиц:

enter image description here

1 Ответ

0 голосов
/ 02 мая 2020

Entity Framework имеет набор универсальных c инструментов для вызова таблицы с TEntityType. Я предполагаю, что самая сложная часть - это динамическое построение фильтров с учетом входных данных от внешнего интерфейса.

Со стороны сервера

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

string myFilterString = "entity => entity.EntityProperty > 100";

Predicate<MyEntity> myFilterPredicate = MyPredicateFactory.BuildFromString<MyEntity>(myFilterString);

var filteredEntities = context.Set<MyEntity>().Where(myFilterPredicate).ToList();

И вы получите filterString с фронта, который будет нести ответственность за его сборку с помощью пользовательского интерфейса, которого он заслуживает.

Это выполнимо, давайте проверим эту статью на простом примере. Вы можете использовать отражение для построения выражений любого типа. https://www.strathweb.com/2018/01/easy-way-to-create-a-c-lambda-expression-from-a-string-with-roslyn/

На внешней стороне

Чтобы всегда не поддерживать синхронизацию c переднюю часть и внутреннюю часть, при каждом изменении внутренней части (свойство переименовывается например), то, что я предлагаю, это динамически построить (на стороне сервера) схему json пригодных для использования фильтруемых объектов и свойств и отправить ее на фронт так или иначе, чтобы, когда фронт получает ее, она знает, какие имена сущностей или свойств можно использовать для создания строковых фильтров.

Таким образом, вы можете переименовывать или добавлять свойства в конец, не беспокоясь о совместимости внешнего интерфейса. Ваш фронт мог бы просто манипулировать новыми свойствами.

Необязательно: другие интересные треки

Если вы не знаете API-интерфейсы GraphQL, вам может быть интересно проверить, сколько это стоит, поскольку с небольшим количеством конфигурации и кода, он поддерживает фильтрацию на стороне клиента.

...