EF Core. Общий контекст на связанные сущности

@2033 · Регистрация: 26.12.2024

Студворк — интернет-сервис помощи студентам

Здравствуйте. Есть проект, в котором есть связанные сущности (один-ко-многим). Набор и значения в этом наборе.
Как я полагаю, я должен создать два репозитория под каждую из этих сущностей. Допустим, с помощью Include я могу получить их в репозитории набора, но если я, к примеру, добавил новый набор и туда добавил значения, или просто в уже существующий набор добавляю значения, как мне обновлять контекст, чтобы все было синхронизировано?

Должен ли у меня быть третий класс, который будет хранить общий контекст на время жизни приложения или еще что-то?

@Usaga · 03.02.2025, 06:20

Сообщение от Vissmuy

который будет хранить общий контекст на время жизни приложения

Вот так точно делать не надо. У контекста есть кеш, который забиваться будет. Контекст нужно создавать на время, пока он нужен. А потом диспоузить.

Сообщение от Vissmuy

как мне обновлять контекст

SaveChanges() ?

@2033 · 03.02.2025, 07:16 **[ТС]**

Сообщение от Usaga

У контекста есть кеш, который забиваться будет.

Так в этом же и суть. Чтобы постоянно к бд не обращаться за данными они кэшируются и берутся из памяти. Просто, думаю, надо следить за его наполнением, дабы в нем лишнего не оказалось, наверное. Поправьте, если не прав.

Сообщение от Usaga

SaveChanges() ?

Хорошо. Допустим у меня есть ViewModel, в котором проинициализированы два репозитория SetRepository и WordRepository.
Для простоты понимания чуть подробней опишу сущности. Set - набор сущностей. Word - это слово. В наборе может быть много слов. К примеру, я хочу в набор добавить слово. Во ViewModel вызываю из WordRepository метод Add. Я в правильном направлении думаю или нет?

Добавлено через 2 минуты
Но контекста то два должно быть. Один в одном репе, другой в другом. Как их связать? Ведь одна сущность связана с другой.

@Usaga · 03.02.2025, 07:29

Сообщение от Vissmuy

Так в этом же и суть. Чтобы постоянно к бд не обращаться за данными они кэшируются и берутся из памяти. Просто, думаю, надо следить за его наполнением, дабы в нем лишнего не оказалось, наверное. Поправьте, если не прав.

Так если нужен кеш, то почему бы его явно не использовать?

Сообщение от Vissmuy

Я в правильном направлении думаю или нет?

Ну да.

Сообщение от Vissmuy

Но контекста то два должно быть. Один в одном репе, другой в другом. Как их связать? Ведь одна сущность связана с другой

Почему два? Можно и один, просто в конструктор репозитория передавать.

@2033 · 03.02.2025, 07:31 **[ТС]**

Сообщение от Usaga

Почему два? Можно и один, просто в конструктор репозитория передавать.

Ну так значит контекст все таки должен быть общий на несколько репов?

@Usaga · 03.02.2025, 07:35

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

@2033 · 03.02.2025, 07:42 **[ТС]**

Usaga, хорошо, я понял.

@kotelok · 03.02.2025, 07:50

Сообщение от Vissmuy

Но контекста то два должно быть.

Зачем вообще их хранить? Потом ещё следить за их состоянием. Потом по какой-то запутанной логике принимать решение о необходимости обновления данных из БД (когда данные там были изменены каким-то другим пользователем/приложением).

Экземпляр контекста создаётся для выполнения конкретной операции, после чего сразу же диспозится.

C#
1
2
3
4
5
6
7
8
9
public int Add(<some raw data>)
{
    using (var ctx = <create context>)
    {
        ....
        ctx.Some.Add(<some entity prepared data>);
        ctx.SaveChanges();
    }
}

@2033 · 03.02.2025, 07:55 **[ТС]**

Сообщение от kotelok

Экземпляр контекста создаётся для выполнения конкретной операции, после чего сразу же диспозится.

Тогда возникает необходимость постоянно обращаться к бд за данными. Данных не мало, не лучше ли их один раз получить и потом использовать из памяти?

@kotelok · 03.02.2025, 07:58

Сообщение от Vissmuy

Данных не мало, не лучше ли их один раз получить и потом использовать из памяти?

Это не задача EF-контекста.

Полученные для отображения данные могут храниться:
1. В свойствах VM, если они нужны для отображения.
2. Где-то в кэше модели, если там и в самом деле очень много данных, к которым нужен ну очень частый доступ, и они редко меняются, а сервер БД (или API) при этом расположен далеко и обращения к нему выполняются слишком медленно.

P.S.: вообще, заморачиваться на кэширование имеет смысл только когда в этом вот прям реальная потребность возникает, потому как это сразу порождает всякие неудобные задачи - например, как принимать решение об актуализации кэша, если данные в БД могут меняться другим пользователем/приложением.

@Usaga · 03.02.2025, 08:58

Сообщение от Vissmuy

Данных не мало, не лучше ли их один раз получить и потом использовать из памяти?

Для этого надо отдельный кеш использовать. Который не будет влиять на производительность обращений к базе и где можно настраивать политику вытеснения\устаревания данных. Не нужно перегружать такой обязанностью бедную ORM.

@2033 · 03.02.2025, 09:20 **[ТС]**

Сообщение от Usaga

Для этого надо отдельный кеш использовать. Который не будет влиять на производительность обращений к базе и где можно настраивать политику вытеснения\устаревания данных. Не нужно перегружать такой обязанностью бедную ORM.

А что значит отдельный кеш? Отдельный от чего?

@Rius · 03.02.2025, 09:26

https://learn.microsoft.com/ru... ew=net-8.0
IMemoryCache типа.

@Usaga · 03.02.2025, 09:27

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

@Calabonga · 15.02.2025, 14:03

Сообщение от Vissmuy

Ну так значит контекст все таки должен быть общий на несколько репов?

Предлагаю посмотреть в сторону "Unit Of Work", возможно его применение решит вашу проблему

@Usaga · 17.02.2025, 06:09

Calabonga, EF уже реализует данный паттерн)

@Calabonga · 17.02.2025, 07:02

Сообщение от Usaga

EF уже реализует данный паттерн)

Это не совсем соответствует действительности, хотя "да", DbContext работает по принципу работы паттерна "Unit of Work", но при этом...

тут показано как при помощи EntityFramework реализовать UnitOfWork. Зачем тогда Microsoft его еще раз реализовывает, если он уже, как вы говорите, реализован?
тут уже другой пример https://antondevtips.com/blog/... in-ef-core
вот еще один хороший пример реализации UnitoOfWork. Опять же показывает, что в EntityFrameworkCore есть UnitOfWork, но его надо использовать, а не надеятся, что он сделать всё за вас.
а вот видео про UnitOfWork и EntityFrameworkCore, которое я делал более трех лет назад. Где как раз рассказал, какие ошибки возникающие при работе с EntityFrameworkCore решает использование паттерна UnitOfWork.

И, кстати, предполагая полемику на предмет "надо" или "не надо" использовать UnitOfWork, приведу свои доводы.

Почему НЕ надо использовать

Вот несколько аргументов в пользу того, чтобы отказаться от реализации паттернов Unit of Work и Repository при использовании EntityFramework Core:

EntityFramework Core изолирует ваш код от базы данных (от любой базы данных)
DbContext работает по принципу работы паттерна Unit of Work
DbSet работает по принципу работы паттерна Repository EntityFramework Core имеет все возможности для Unit-тестирования (в том числе и без использования паттерна Repository)

Почему надо использовать

А вот несколько контрагрументов в ответ на аргументы из предыдущего параграфа:

EntityFramework Core не дает возможности получить "из коробки" фильтрованные данные для разбития на страницы (paging), то есть нет методов типа GetPagedList<T> или GetPagedListAsync<T>
EntityFramework Core не имеет возможности выдавать данные по запросы на основании ролей (прав доступа или разрешений) при выборки из базы данных, то есть вам так или иначе придется реализовывать выборки на основании ролей в каком-то слое (вы можете его называть как угодно, некоторые его называют Unit of Work).
EntityFramework Core реализует доступ к данным, но никоим образом не призван реализовывать механизмы, обслуживающие ваши бизнес-процессы. Реализация бизнес-процессов, обычно начинается на уровне Repository и продолжается на уровне Unit of Work. Значит вам придется базовые принципы реализовывать самостоятельно (принципы доступа, трансформации, агрегации и т.д.). А это уже, так или иначе, Unit of Work, ну или какая-то его часть.

В любом случае, любой инструмент, нужно использовать по назначению.

@Usaga · 17.02.2025, 07:58

Calabonga, EF уже реализует данный паттерн)

Сообщение от Calabonga

EntityFramework Core не дает возможности получить "из коробки" фильтрованные данные для разбития на страницы (paging), то есть нет методов типа GetPagedList<T> или GetPagedListAsync<T>

Да вообще-то всю дорогу были методы Skip и Take, которые пагинацию и реализуют...

@Calabonga · 17.02.2025, 08:08

Сообщение от Usaga

Да вообще-то всю дорогу были методы Skip и Take,

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

@Usaga · 17.02.2025, 08:16

Calabonga, какие данные прописывать?

Новые блоги и статьи Все статьи Все блоги /
Рисование коллайдеров Box2D v2 на Three.js с помощью порта @box2d/core 8Observer8 06.06.2025 Используется порт Box2D v2 под названием @box2d/ core - пакет NPM. Загрузил документацию Box2D v2 на Netlify: https:/ / box2d-v2-docs. netlify. app/ Документацию Box2D v2 можно скачать с официального. . .	Как создать стек в Python AI_Generated 05.06.2025 Как архитектор с более чем десятилетним опытом работы с Python, я неоднократно убеждался, что знание низкоуровневых механизмов работы стеков дает конкурентное преимущество при решении сложных задач. . . .	Server-Sent Events (SSE) в Node.js run.dev 05.06.2025 Потоковая передача данных с сервера прямо в браузер стала повседневной потребностью - от биржевых графиков и спортивных трансляций до чатов и умных дашбордов. Много лет разработчики полагались на. . .	Создаем RESTful API на Golang с Fiber golander 04.06.2025 Я перепробовал десятки фреймворков для создания RESTful API за последние годы, и когда впервые столкнулся с Fiber, понял, что это совсем другой уровень. Нет, я не собираюсь рассказывать сказки о. . .	Как работать с куки в ASP.NET Core UnmanagedCoder 04.06.2025 Когда я впервые начал работать с куки в ASP. NET Core, меня поразило, насколько отличается работа с ними от классического ASP. NET. В Core все стало более декомпозированным - больше нет удобного. . .
Рисование коллайдеров физического движка Box2D-WASM v3 на Three.js 8Observer8 04.06.2025 Erin Catto (автор Box2D) переписал с нуля Box2D v2 с С++ на Си и появилась версия Box2D v3. Birch-san собрал Box2D v3 в WebAssembly (WASM), чтобы можно было использовать Box2D v3 на JavaScript. В. . .	Worker Threads и многопоточность в Node.js Reangularity 03.06.2025 Если вы когда-нибудь посещали собеседования на позицию Node. js разработчика, почти наверняка слышали заезженную фразу: "Node. js - однопоточная платформа". Звучит как неоспоримый факт, который. . .	Event-Driven CQRS на C# с паттерном Outbox stackOverflow 03.06.2025 В традиционной модели происходит примерно следующее: вы получаете команду, обрабатываете ее, сохраняете результат в базу данных и затем пытаетесь опубликовать событие в брокер сообщений. Но что если. . .	OwenLogic: перенос сетевых переменных в панель Weintek (EasyBuilder Pro) ФедосеевПавел 03.06.2025 ВВЕДЕНИЕ ПЕРЕД ЭКСПЕРИМЕНТАМИ - СОЗДАЙТЕ РЕЗЕРВНЫЕ КОПИИ ПРОЕКТОВ На момент написания статьи (02 июня 2025 г. ) самыми актуальными версиями ПО являются: OwenLogic v. 2. 10. 366 EasyBuilder Pro. . .	Dev-c++5.11 Покорение вершины russiannick 02.06.2025 С утра преследовала одна мысль - вот бы выучить С++. Сказано-сделано. Окончив смену, скачал в интернете бестселлер Дэвиса Dev-C++ для чайников. Книга оказалась интересной и я скачал среду, на примере. . .

@2033 4 / 4 / 1 Регистрация: 26.12.2024 Сообщений: 223

	.NET 9 EF Core. Общий контекст на связанные сущности 03.02.2025, 04:27. Показов 1869. Ответов 23 Метки .net 9, dbcontext, ef core (Все метки) Здравствуйте. Есть проект, в котором есть связанные сущности (один-ко-многим). Набор и значения в этом наборе. Как я полагаю, я должен создать два репозитория под каждую из этих сущностей. Допустим, с помощью `Include` я могу получить их в репозитории набора, но если я, к примеру, добавил новый набор и туда добавил значения, или просто в уже существующий набор добавляю значения, как мне обновлять контекст, чтобы все было синхронизировано? Должен ли у меня быть третий класс, который будет хранить общий контекст на время жизни приложения или еще что-то? 0

@Usaga 13481 / 9013 / 1326 Регистрация: 21.01.2016 Сообщений: 33,826
	03.02.2025, 07:35
	Vissmuy, если есть веские причины разные использовать, то можно и разные. Но обычно так не делают и переиспользуют один. 0

@2033 4 / 4 / 1 Регистрация: 26.12.2024 Сообщений: 223
	03.02.2025, 07:42 [ТС]
	Usaga, хорошо, я понял. 0

@Rius 12350 / 7335 / 1625 Регистрация: 25.05.2015 Сообщений: 22,193 Записей в блоге: 14
	03.02.2025, 09:26
	https://learn.microsoft.com/ru... ew=net-8.0 IMemoryCache типа. 1

@Usaga 13481 / 9013 / 1326 Регистрация: 21.01.2016 Сообщений: 33,826
	03.02.2025, 09:27
	Vissmuy, в смысле код, умышленно реализующий функционал кеширования. А не эксплуатирование побочных эффектов того, что под это прямо не задумывалось. 1

@Usaga 13481 / 9013 / 1326 Регистрация: 21.01.2016 Сообщений: 33,826
	17.02.2025, 06:09
	Calabonga, EF уже реализует данный паттерн) 0

@Usaga 13481 / 9013 / 1326 Регистрация: 21.01.2016 Сообщений: 33,826
	17.02.2025, 08:16
	Calabonga, какие данные прописывать? 0