Включение свойств навигации в EF Core при вызове хранимой процедуры
У меня есть хранимая процедура SQL Server, которая выбирает объекты из таблицы Records, и у меня есть еще одна таблица, в которой есть множество файлов для каждой сущности Record в отношении один-ко-многим.
Я создал хранимую процедуру, и она правильно выбирает данные с левым соединением для таблицы Files. Теперь я хочу заполнить свойство Files для каждой записи точно так же, как когда я создавал .Include(x => x.Files) в EF Core. В конечном итоге это всегда null.
Вот как я вызываю хранимую процедуру:
const contentTypeParam = new SqlParameter("@ContentTypeId", contentTypeId);
const result = await _context.GetRecords
.FromSqlRaw("EXEC GetListRecords @TypeId", contentTypeParam)
.ToListAsync();
Моя хранимая процедура содержит этот оператор SQL:
SELECT r.*
FROM Records
LEFT JOIN Files f ON f.RecordId = r.Id;
EF просто получает набор результатов от хранимой процедуры и использует соответствующие данные для заполнения сущностных объектов. Это все, что он может сделать. (И это потерпит неудачу, если соединения вызовут дубликаты.) Вам придется использовать Record в обычном запросе на Include.
Ответы 1
Короткий ответ: «Нет».
«Структура сущностей ---» .. (я буду использовать этот термин) «--обходной путь» .. заключается в том, что ЕСЛИ ваша хранимая процедура имеет НЕСКОЛЬКО операторов «SELECT», вы можете неохотно сопоставить каждый «.Result» с некоторая эф-сущность.
Я буду использовать общий пример.
хранимая процедура:
SELECT d.DepartmentKey, d.DepartmentName FROM dbo.Department d;
SELECT e.EmployeeKey, e.ParentDepartmentKey, e.LastName, e.FirstName FROM dbo.Employee e;
это возвращает ДВА ".Results".
Вы можете следить за такой статьей:
или вы можете выполнить поиск по этой фразе (ниже) в Интернете и найти несколько статей.
ядро структуры сущности «NextResult»
ТЕПЕРЬ, самая сложная часть заключается в том, что... имя вашего объекта ДОЛЖНО ТОЧНО СООТВЕТСТВОВАТЬ именам столбцов вашего SELECT.
То есть, используя приведенный выше пример, ваш DepartmentEfEntity.cs ДОЛЖЕН иметь имена свойств, называемые DepartmentKey, DepartmentName .. без отклонений.
Вот почему мне не нравится эта работа.
Вот дополнительная ссылка (пусть и не "основная") на имена объектов и столбцов.. "должна быть точной" : https://learn.microsoft.com/en-us/ef/ef6/modeling/designer /advanced/multiple-result-sets
- Если у вас есть SINGLE SELECT с предложениями JOIN(s)... вы не можете сделать это с помощью Entity-Framework (или, по крайней мере, насколько мне известно).
ВАРИАНТ — Dapper «Split On».
https://www.learndapper.com/relationships#dapper-spliton
это позволит вам «сопоставить» операторы 1:N «JOIN» с некоторыми объектами-сущностями.
Однако я думаю, что одно и то же «Имя столбца» и «Имя свойства»… точное совпадение… должно существовать.
.......
В конечном счете, вам следует спросить себя, почему вы вообще используете хранимую процедуру. «Потому что оно уже существовало», вероятно, не является веской причиной, ИМХО.
Что я делаю, так это... "использую EF... "как было задумано"" (см. комментарий "@Gert A" к вашему исходному вопросу)....до такой степени, что у меня есть особый случай, который мне нужен ПРОИЗВОДИТЕЛЬНОСТЬ. а затем я смирился с препятствиями/болью прямого вызова хранимой процедуры.
Я склоняюсь к №2. У меня будет хранимая процедура, возвращающая несколько .Result(s) (и использую .NextResult). Я узнал, что в долгосрочной перспективе это более ремонтопригодно. проблема с JOIN заключается в том, что
(1) у вас есть повторяющаяся информация (когда вы объединяете таблицу отделов и таблицу сотрудников в единый объединенный выбор, ключ отдела и имя отдела будут повторяться много раз.
и (2) когда вам нужен новый столбец... это требует изменений в нескольких местах кода.
Я выберу №3… несколько раз. Обычно это касается «специализированной ситуации с отчетами»...
Но это требует большего внимания к №2 и №3. Я плачу стоимость обслуживания... когда мне нужна конкретная ситуация... обычно связанная с производительностью.
Надеюсь, это поможет.
ДОБАВИТЬ (к этому ответу):
Вот отличная статья, в которой рассматривается множество различных вариантов.
https://khalidabuhakmeh.com/multiple-result-sets-with-net-core-sql-server
Ниже приведен один абзац из приведенного выше ответа на случай, если ссылка выше будет «переработана» со временем...
В этом посте мы будем иметь дело с простой базой данных, состоящей из две таблицы: Люди и Еда. Существует связь один-ко-многим между людьми и едой. Сами таблицы ничем не примечательны, и в этом посте я даже не беспокоюсь о правильности схемы.
Вы не можете. Эта хранимая процедура не создается EF Core, как SQL, созданный на основе запроса LINQ, и EF Core не может отслеживать, что и почему следует инициализировать.