Совместное использование / расширение DbContext из базового приложения MVC. NET в библиотеку классов (Razor) - PullRequest
Новая
       8

Совместное использование / расширение DbContext из базового приложения MVC. NET в библиотеку классов (Razor)

0 голосов
/ 04 февраля 2020

У меня есть веб-приложение с собственным dbcontext (context1), и у меня есть библиотека классов Razor с другим dbcontext (context2). В идеале у меня должен быть один контекст БД ...

Проблема, с которой я сталкиваюсь, заключается в том, что некоторые таблицы «перекрываются», например, context1 содержит компании-сущности, а context2 содержит пользователей-сущностей, однако между компаниями и пользователи.

  • Есть ли способ, которым я могу исключить context2 из моего CL и каким-то образом вставить context1 в мою библиотеку классов?

  • Или, возможно, есть способ, которым я могу наследовать context2 к context1?

  • В качестве альтернативы, если я сохраняю два контекста, могу ли я не допускать "перекрытия", например, создать представление, чтобы разрешить навигационные свойства между двумя контексты? (просто мысли вслух)

Любой совет очень ценится.

Спасибо

1 Ответ

0 голосов
/ 05 февраля 2020

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

Например, если у меня есть некоторый код в MVC проекте, который выполняет что-то вроде: 

using (var context = new AppContext())
{
     var myEntity = context.Entities.Single(x => x.EntityId = entityId);
     SomeService.DoSomething(myEntity);
}

, а служебная библиотека делает что-то вроде: 

public void DoSomething(AppEntity someEntity)
{
    using(var context = new AppContext())
    {
        someEntity.Status = "DidSomething";
        context.Attach(someEntity);
        context.Entity(someEntity).State = EntityState.Modified;
        context.SaveChanges();
    }
}

или что-то подобное, тогда вы, вероятно, готовитесь к миру дискомфорта, отслеживая устаревшие проблемы, связанные с состоянием. Оба блока кода могут ссылаться на один и тот же DbContext тип , но на разные DbContext instance , что означает, что ссылка DbContext контроллера может не отражать или отслеживать объекты, которые были переданы другим контекстом библиотеки .

Как правило, объект не должен покидать область действия экземпляра DbContext, который его породил. Любая сущность, которая действительно должна считаться отсоединенной, но если она явно не отделена от экземпляра DbContext, это может привести к ошибкам в будущем, в зависимости от того, как долго был создан DbContext, который его породил. Если одна сборка ссылается на вторую сборку, то вы можете использовать Dependency Injection и контейнер Io C для управления областью действия одного экземпляра DbContext на протяжении всего вызова, а также вы можете использовать провайдера Unit of Work для предоставления DbContext и управления временем жизни. этого DbContext. Таким образом, когда на вашу библиотеку ссылается MVC, она разделяет экземпляр DbContext при вызове, но если вызывается с помощью другого средства, она разрешает подходящий экземпляр DbContext для сущностей, полученных из этого сценария.

Для более крупных систем целесообразно использовать отдельные определения DbContext и упрощенные определения сущностей. Меньшие, более простые, недолговечные DbContexts работают более эффективно при запросах / отслеживании объектов. Для служб, которые могут вызываться часто для работы с данными, может быть гораздо лучше иметь упрощенную сущность для меньшего DbContext. Получать объект, проверять, изменять и фиксировать, а не пытаться присоединять, изменять и фиксировать, используя полноразмерный объект в полноразмерном экземпляре DbContext Модели, подобные этой, будут использовать полезные нагрузки минимального размера (DTO), а не объекты в качестве полезных нагрузок. Вызывающие абоненты получат указание, что их объекты должны быть обновлены или нет.

...