Объединение нескольких контекстов базы данных в ASP.Net MVC

Фон:

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

Вопрос:

Как бы я переписал каждый из моих классов в подкаталогах папки области, чтобы исключить отдельные вызовы миграции?

Источник:

Команды переноса базы данных ниже

Создание миграций для корневых моделей

Enable-Migrations -ContextTypeName:JosephMCasey.Models.ApplicationDbContext -MigrationsDirectory:Migrations\Root
Add-Migration -configuration JosephMCasey.Migrations.Root.Configuration Root
Update-Database -configuration JosephMCasey.Migrations.Root.Configuration -Verbose

Установка миграций для каждой модели «Области»

Enable-Migrations -ContextTypeName:JosephMCasey.Areas.Article.Models.ApplicationDbContext -MigrationsDirectory:Migrations\Article
Add-Migration -configuration JosephMCasey.Migrations.Article.Configuration Article
Update-Database -configuration JosephMCasey.Migrations.Article.Configuration -Verbose

Идеализированные миграции

Enable-Migrations
Add-Migration Application
Update-Database

Классы C# ниже

Приложение\Модели\ИдентитиМоделс.КС

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection", throwIfV1Schema: false)
    {
    }

    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }
}

Приложение\Области\Статья\Модели\Статья.cs

namespace JosephMCasey.Areas.Article.Models
{
    public class ArticleContent
    {
    ...
    }
    public class ApplicationDBContext : DbContext
    {
        public DbSet<ArticleContent> Articles { get; set; }
        public DbSet<Category> Categories { get; set; }
        public DbSet<Tag> Tags { get; set; }
    }
}

Конечная нота

Я просто слишком ленив или придирчив? Разве не более эффективно запускать один контекст? Я новичок в этом, поэтому мое понимание лучших практик в лучшем случае шатко.

Ресурсы для руководства

Первая миграция кода в нескольких контекстах DbContext

Наследование в Entity Framework: Таблица для каждой иерархии

Форумы ASP.Net

Команды консоли диспетчера пакетов — get-help Enable-Migrations -detailed и get-help Add-Migration -detailed и get-help Update-Database -detailed


c# asp.net asp.net-mvc asp.net-mvc-4 entity-framework-migrations
person Joseph Casey    schedule 20.05.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Каждый уникальный контекст необходимо мигрировать отдельно. Нет никакого способа обойти это. Если вы хотите выполнить только одну миграцию, вы должны объединить все контексты в один контекст. Лично я бы рекомендовал сделать это, в любом случае. Нет необходимости в нескольких контекстах для обслуживания одного приложения, если только некоторые из них не предназначены для подключения к существующим базам данных. В этом случае вам все равно не нужно будет их мигрировать.

ОБНОВЛЕНИЕ

Я до сих пор не уверен, как я могу объединить все это, чтобы создать единый контекст.

На базовом уровне ваш единственный контекст просто должен ссылаться на все различные пространства имен модели области:

using AwesomeApp.Areas.Foo.Models;
using AwesomeApp.Areas.Bar.Models;
using AwesomeApp.Areas.Baz.Models;

public class AwesomeAppContext : DbContext
{
    // DbSets for each areas entities here
}

Однако было бы предпочтительнее просто реорганизовать свой проект. Классы сущностей не нужно помещать в каталог «Модели», и их не нужно хранить вместе с областью, в которой они используются. Лично, если я делаю относительно простое приложение MVC, я обычно резервирую основной каталог «Модели» в корне проекта для всех сущностей, используемых приложением, вместе с одним контекстом, который ссылается на каждую из них.

Для более сложных приложений я полностью выношу это за пределы проекта, и все мои сущности и мой контекст живут в библиотеке классов. Затем я переношу библиотеку классов и просто добавляю ее в качестве ссылки на проекты, которым нужны эти объекты.

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

person Chris Pratt    schedule 20.05.2015
comment
Я знаю, что это очень начинающий вопрос, но как бы вы написали для Article.cs как наследство от IdentityModels.cs, не помещая их в один и тот же файл? Вы бы изменили пространство имен JosephMCasey.Areas.Article.Models на пространство имен JosephMCasey.Models, как это отражено в IdentityModels.cs? - person Joseph Casey; 20.05.2015
comment
Файлы и их пути не имеют ничего общего с кодом внутри. Для простоты Visual Studio использует путь для создания пространства имен при создании нового файла класса, но пространство имен может быть любым, которое вы хотите. Однако даже в этом случае ваши классы не обязательно должны находиться в одном и том же пространстве имен, чтобы использовать друг друга. Вам просто нужно добавить оператор using в свой код, чтобы включить другое пространство имен, и вы готовы к гонкам. - person Chris Pratt; 20.05.2015
comment
По сути, вы говорите, что пространства имен предназначены для определения области видимости, а их имена произвольны. Использование предназначено для включения переменных из одной области в другую. Тем не менее, я до сих пор не уверен, как я могу объединить все это, чтобы создать единый контекст. Я опубликую, как только узнаю, что я делаю неправильно. - person Joseph Casey; 20.05.2015
comment
Я бы не стал утверждать, что пространства имен произвольны, но да, они предназначены только для определения области видимости. Например, в библиотеке классов для продукта, над которым я работаю, фактические файлы .cs организованы в иерархии каталогов в решении, но каждый отдельный класс имеет пространство имен в форме Foo.Lib. В результате, включая это пространство имен, вы можете получить доступ ко всему в библиотеке классов, а каталоги предназначены только для организации в рамках решения. - person Chris Pratt; 20.05.2015
comment
Спасибо за ответ. Мне определенно нужно было знать, как должны храниться мои модели. Я попытался найти другие веб-проекты C# на GitHub, чтобы посмотреть, как они выполняют эту задачу, но не смог найти каталог, явно содержащий модели. - person Joseph Casey; 20.05.2015