EF Core: любая причина не бросать QueryClientEvaluationWarning - PullRequest
2 голосов
/ 20 сентября 2019

EF Core имеет функцию , где он может оценивать части запроса в памяти, когда эта часть не может быть выполнена в БД.Когда это происходит, регистрируется предупреждение.

Опционально EF Core может быть настроен на выдачу исключения, когда это происходит

optionsBuilder
        .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFQuerying;Trusted_Connection=True;")
        .ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning)); // <--

После оценки чего-либо в памяти, что программист намеревался выполнить вБД может быть огромной проблемой производительности и несколько нечистой imho Я сейчас думаю об использовании этой конфигурации исключений везде и всегда.

Мне просто интересно, есть ли какие-нибудьвеские причины не бросать исключение?Лично я предпочел бы исключение, а затем изменить код, который будет выполняться преднамеренно в памяти (например, с помощью .ToList() перед проблемным оператором).Мне странно, что EF просто обошел бы такой недостаток дизайна.

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

1 Ответ

2 голосов
/ 20 сентября 2019

Хорошая причина не создавать исключение - это когда вы используете нереляционную базу данных и вам придется обрабатывать и искать данные в своем коде.Другой случай может быть, если вы используете запрос linq для объединения данных из нескольких источников - структуры данных в памяти, XML, базы данных и ожидаете, что вы будете только читать из этих источников и выполнять всю обработку в вашем коде.

Однако, когда вы ориентируетесь только на реляционные базы данных, вы всегда должны бросать.

...