#entity-framework #entity-framework-core #asp.net-core-webapi
#entity-framework #entity-framework-core #asp.net-core-webapi
Вопрос:
У меня есть 2 таблицы со следующей структурой:
Пользователь
UserId | Age
----------------
1 15
2 36
3 25
Диктанты
Title | FromAge | ToAge
-------------------------------
1 0 20
2 20 35
3 35 100
Я создал необходимые модели для DbContext, вызываемые UserModel
и DictAgesModel
с точно такими же свойствами, показанными в структуре таблицы. Я хотел бы запросить пользователя с его идентификатором и присоединить заголовок в зависимости от возраста пользователя. Вот код MySQL, который я использовал раньше:
SELECT User.UserId, DictAges.Title
FROM User, DictAges
WHERE User.UserId = :id
AND User.Age BETWEEN DictAges.FromAge AND DictAges.ToAge
Обратите внимание, что у меня нет никакого свойства навигации, добавленного ни к одной из этих моделей (должен ли я добавить его ??)
Как я мог бы перевести подобный запрос в основной запрос entity framework?
Ответ №1:
Следовательно, у вас нет навигационных свойств, вы можете сделать, как показано ниже.
Запрос на основе :
from p in ctx.User
join q in ctx.DictAges on p.UserId equals q.Title
where p.UserId == :id AND p.Age BETWEEN q.FromAge AND q.ToAge
select new {UserId = p.UserId, Title = q.Title };
Метод на основе :
ctx.User.Join(ctx.DictAges,
p => p.UserId,
q => q.Title,
(p, q) => new { User = p, DictAges = q })
.Where(s => s.User.UserId == :id amp;amp; (s.DictAges.FromAge <= s.User.Age amp;amp; s.User.Age <= s.DictAges.ToAge) )
.Select(ss => new { UserId = ss.User.UserId, Title = ss.DictAges.Title});
Примечание: следовательно, у вас нет свойств навигации, синтаксис на основе методов очень сложный.Другими словами, существуют проблемы с удобочитаемостью. Из-за этого я хотел бы, чтобы синтаксис запроса основывался на этих ситуациях.
Обновить :
Вы можете узнать о свойствах навигации, используя эту статью : Отношения
Комментарии:
1. не могли бы вы написать версию lamdba, если я не прошу слишком многого?
2. Выглядит неплохо, я скоро попробую. До тех пор, не могли бы вы добавить дополнительную информацию о свойствах навигации, я имею в виду, какой класс должен иметь его и как это повлияет на сам запрос? В любом случае, спасибо, если данный код работает для моего решения, я все равно приму ваш ответ.
3. Я обновил сообщение. пожалуйста, следуйте упомянутой статье. Это объясняет все о навигационных свойствах в ядре EF.
4. Странно, что это принято, поскольку ни один из двух предоставленных запросов не даст того же результата, что и исходный SQL (первый даже не компилируется). И свойства навигации не могут использоваться для создания корреляции диапазонов.
5. Принятые решения не всегда идеально компилируются и работают. Но самое главное — это направление, которое решение показывает OP. Если это направление правильное, то OP может настроить его в соответствии со своим приложением. @IvanStoev