Обединяване на множество контексти на база данни в 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# класове по-долу

Application\Models\IdentityModels.cs

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

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

Application\Areas\Article\Models\Article.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; }
    }
}

Крайна бележка

Просто съм прекалено мързелив или придирчив? Не е ли по-ефективно да се изпълнява един контекст? Нов съм в това, така че разбирането ми за най-добрите практики е в най-добрия случай нестабилно.


Ресурси за насоки

Code First Migration in Multiple DbContext

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

ASP.Net форуми

Конзолни команди на Package Manager - get-help Enable-Migrations -detailed & get-help Add-Migration -detailed & get-help Update-Database -detailed


person Joseph Casey    schedule 20.05.2015    source източник


Отговори (1)


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

АКТУАЛИЗАЦИЯ

Все още не съм сигурен как мога да обединя всичко това, за да създам един контекст.

На основно ниво, вашият единствен контекст ще трябва просто да препраща към всички различни пространства на имена на модели на области:

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 приложение, обикновено запазвам главната директория „Models“ в корена на проекта за всички обекти, които приложението използва заедно с един контекст, който препраща към всеки.

За по-сложни приложения премествам това напълно извън проекта и оставям всичките си обекти и моя контекст да живеят в библиотека от класове. След това мигрирам срещу библиотеката на класове и просто я добавям като препратка към проекта(ите), които се нуждаят от тези обекти.

Без значение какво правите, въпреки че наличието на обекти, разпръснати навсякъде между различни области, ще превърне поддръжката в кървав кошмар, тъй като винаги ще трябва да помните кое образувание върви с коя област и не дай си боже дори да има някакво кървене там, където започнете да използвайте един и същи обект в множество различни области, но той е дефиниран само в една.

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 използва пътя за конструиране на пространство от имена, когато генерира нов клас файл, но пространството от имена може да бъде каквото искате. Въпреки това, дори тогава, вашите класове не трябва да бъдат в едно и също пространство от имена, за да се използват един друг. Просто трябва да добавите израз за използване към кода си, за да включите другото пространство от имена, и ще започнете състезанията. - 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