Entity framework core

Способ создания переиспользуемых Linq фильтров (построителей предикатов для условия Where), которые можно применять для разных типов объектов. Поля объектов для фильтрации указываются с помощью MemberExpression.

Способ подходит для Entity Framework, включая Async операции.

Основная идея. Что такое переиспользуемый фильтр?

Например есть приказы:

class Order { public DateTime Start { get; set; }public DateTime? End { get; set; }}

Пусть нужно найти все приказы которые будут действовать в ближайшие 7 дней.

С помощью переиспользуемого построителя фильтра (если бы он был реализован) найти приказы можно так:

var ordersFiltred = orders.WhereOverlap(// с помощью MemberExpressions// указываем по каким полям производить поискfromField: oo => oo.Start,toField: oo => oo.End,// указываем период поискаfrom: DateTime.Now,to: DateTime.Now.AddDays(7)).ToList();

Этот же WhereOverlap можно переиспользовать и применить к другому типу. Например, для поиска командировок:

class Trip { public DateTime? From { get; set; }public DateTime? To { get; set; }}

var tripsFiltred = trips.WhereOverlap(// с помощью MemberExpressions// указываем по каким полям производить поискfromField: oo => oo.From,toField: oo => oo.To,from: DateTime.Now,to: DateTime.Now.AddDays(7)).ToList();

Приказы и командировки - это разные типы объектов, у них нет общего интерфейса, поля для поиска называются по-разному. И все таки для обоих типов (и приказов и командировок) применяется один переиспользуемый фильтр WhereOverlap.

Ниже описано как можно делать такие переиспользуемые построители предикатов.

Как сделать переиспользуемый фильтр

Выше было описано применение WhereOverlap, было бы логично показать его реализацию. Но для того, чтобы сделать WhereOverlap, нужна реализация операторов И, ИЛИ. Поэтому начнем с более простого примера.

Пусть есть выплаты и премии:

class Payout { public decimal Total { get; set; }public bool UnderControl { get; set; }}class Premium {public decimal Sum { get; set; }public bool RequiresConfirmation { get; set; }}

Сделаем переиспользуемый фильтр для поиска платежей больше определенной суммы:

class UnderControlPayFilter {readonly decimal Limit;public UnderControlPayFilter(decimal limit) {Limit = limit;}public Expression<Func<TEnt, bool>> Create<TEnt>(Expression<Func<TEnt, decimal>> sumField) {// GreaterOrEqual - нужно реализовать// GreaterOrEqual - это extension, который принимает//  - указание на поле (Expression sumField)//  - и значение с которым нужно сравнивать (Limit)return sumField.GreaterOrEqual(Limit);}}

Пример использования UnderControlPayFilter фильтра:

// фильтр поиска платежей требующих дополнительного контроля//// конкретный предел (здесь 1000) можно вынести в настройки,// а UnderControlPayFilter зарегистрировать в IoC-контейнере.// Тогда можно централизовано (через найстройки приложения)// управлять максимальным пределомvar underControlPayFilter = new UnderControlPayFilter(1000);//// Применение переиспользуемого фильтра для выплатvar payoutPredicate =underControlPayFilter.Create<Payout>(pp => pp.Total);// здесь, для упрощения, payouts - это массив,// в реальном приложении это может быть Entity Framework DbSet var payouts = new[] {new Payout{ Total = 100 },new Payout{ Total = 50, UnderControl = true },new Payout{ Total = 25.5m },new Payout{ Total = 1050.67m }}.AsQueryable().Where(payoutPredicate).ToList();//// Применение переиспользуемого фильтра для премийvar premiumPredicate =underControlPayFilter.Create<Premium>(pp => pp.Sum);// здесь, для упрощения, premiums - это массив,// в реальном приложении это может быть Entity Framework DbSet var premiums = new[] {new Premium{ Sum = 2000 },new Premium{ Sum = 50.08m },new Premium{ Sum = 25.5m, RequiresConfirmation = true },new Premium{ Sum = 1070.07m }}.AsQueryable().Where(premiumPredicate).ToList();

Все готово, осталось только реализовать GreaterOrEqual extension:

public static class MemberExpressionExtensions {    public static Expression<Func<TEnt, bool>> GreaterOrEqual<TEnt, TProp>(        this Expression<Func<TEnt, TProp>> field, TProp val)            => Expression.Lambda<Func<TEnt, bool>>(                Expression.GreaterThanOrEqual(field.Body, Expression.Constant(val, typeof(TProp))),                 field.Parameters);}

По аналогии можно реализовать extension-ы LessOrEqual, Equal, HasNoVal и другие.

Более сложные переиспользуемые фильтры с операторами И и ИЛИ

Пускай в выборку должны попадать не только платежи больше определенного предела, но и те, которые специально отмечены, как требующие дополнительного контроля.

Дополним UnderControlPayFilter:

class UnderControlPayFilter {readonly decimal Limit;public UnderControlPayFilter(decimal limit) {Limit = limit;}public Expression<Func<TEnt, bool>> Create<TEnt>(Expression<Func<TEnt, decimal>> sumField,Expression<Func<TEnt, bool>> controlMarkField) {// PredicateBuilder нужно реализовать (см. ниже)return PredicateBuilder.Or(sumField.GreaterOrEqual(Limit),controlMarkField.Equal(true));}}

Пример использования:

// для выплатvar payoutPredicate =underControlPayFilter.Create<Payout>(sumField: pp => pp.Total,controlMarkField: pp => pp.UnderControl);// для премийvar premiumPredicate = underControlPayFilter.Create<Premium>(sumField: pp => pp.Sum,controlMarkField: pp => pp.RequiresConfirmation);

PredicateBuilder это A universal PredicateBuilder сделанный Pete Montgomery.

Заключение

Чтобы делать свои переиспользуемые фильтры, нужен только PredicateBuilder и MemberExpressionExtensions. Просто скопируйте их в свой проект. Переиспользуемые фильтры можно оформить как extension (как WhereOverlap), как статический хелпер или класс (как UnderControlPayFilter).

Я сделал парочку переиспользуемых фильтров - GitHub, NuGet (включает PredicateBuilder и MemberExpressionExtensions).

Данная статья не является инструкцией по работе с EF миграциями. Здесь не будет инфы о том, как их создавать. Здесь я собрал несколько скользких моментов и попытки их обойти. Давайте начнем!

Старт миграций при запуске приложения

Вам знаком следующий код?

context.Database.Migrate();

Если да, вероятнее всего вы накатываете миграции автоматически при старте проекта. Плохо это или хорошо, можете обсудить в комментариях. Я же в свою очередь хочу предостеречь вот от чего.

Когда вы в cmd, PS или в консоли диспетчера пакетов вызываете какую либо операцию, связанную с миграциями, эта операция включает в явном или неявном виде 2 параметра: проект и запускаемый проект. Проект - это сборка, в которую в конечном счете будут помещены миграции. А вот запускаемый проект - проект, выбранный запускаемым для данного решения (sln). При работе через консоль диспетчера пакетов вы этот параметр никогда не увидите.

Что это означает? А то, что ваш запускаемый проект при выполнении операции с миграциями будет собран (ну об этом вы знаете) и запущен. А это, в свою очередь, означает, что помимо всяких интеграционных штук, которые неожиданно для вас могут отработать, выполнение может дойти до кода, приведенного выше. К чему это может привести? К тому, что текущая операция с миграциями накатит предыдущую созданную вами миграцию. То есть, вы создаете миграцию, тут же, замечаете, что допустили ошибку в настройке сущности, пытаетесь ее удалить через Remove-Migration, но получаете от ворот поворот, потому что в момент запуска операции удаления миграции, она накатывается на базу. Вы, конечно же, выполняете роллбэк последней миграции и затем снова вызываете Remove-Migration. Но, угадайте, что произойдет?

Чтобы это побороть, могу подсказать 2 подхода:

1. Не использовать применение миграций при запуске проекта

2. Использовать в качестве запускаемого проекта для операций с миграциями отдельный консольный запускаемый проект.

Если есть идеи лучше, пишите в комментариях. С удовольствием обсужу с вами и приму к сведению.

Удаление миграций

В общем-то, удалять миграции я рекомендую только в двух случаях:

1. Миграция приводит к потере данных и пока код не добрался до прода, миграцию можно и нужно вычленить.

2. Миграция еще не слита в ветку, вы создали ее локально, но она не правильная.

Во втором случае можно удалить последнюю миграцию, использовав команду Remove-Migration. Если миграцию уже применили к базе, надо ее предварительно откатить. После выполнения Remove-Migration почистите мусор в файле проекта (csproj). Так же, если у вас всего одна миграция или несколько, но еще не закоммичены, быстрее будет откатить снапшот через Git (или вашу систему контроля версий) и удалить файлы миграций.

В данном случае универсальным решением будет откатить базу до удаляемой миграции, удалить все миграции после проблемной (вместе с ней). Мусор в csproj файле при этом чистить не надо.

Создание SQL миграций

Возможно, не все знают, но на основе разработческих миграций (тех, что создаются в коде, это майки их где-то так называли) можно создать SQL скрипты. Для этого есть команда Script-Migration. С ее помощью можно создать в т. ч. идемпотентные скрипты.

А начиная с версии EF Core 3.0 появилась команда Script-DbContext для создания миграций из контекста базы.

При развертывании, конечно, потребуется механизм для запуска этих скриптов, но зато это принесет плоды, когда в случаях возможной потери данных вы сможете добавить SQL прямо внутрь нужной миграции и вам не придется пересобирать проект.

Редактирование сущностей

Нут тут, казалось бы, все просто. Мы меняем что-либо в сущности, создаем миграцию, радуемся результату. Вот только результат может быть неожиданным, когда вам нужно удалить одно поле и создать другое того же типа. Мигратор при этом создаст команду для переименования столбца в БД. Все данные из удаляемого столбца, соответственно, перенесутся в новый. В данном случае можно создать 2 миграции: для удаления столбца и для создания нового. После этого, чтобы не маячили 2 миграции вместо одной, можно совместить их код Up и Down и последнюю удалить.

Заключение

В заключении хочу сказать, будьте внимательны к данным, проверяйте новые миграции, вдумывайтесь в них, не бойтесь их редактировать. А на всякие неочевидные грабли при работе с EF вы все равно наступите.