CODEWITHSUNDEEP
c#asp.netasp.net-mvcasp.net-mvc-4entity-framework-migrations
Joseph Casey
Joseph Casey

Reputation: 1303

Merging multiple database contexts in ASP.Net MVC

Background:

I have multiple classes called ApplicationDbContext. One is located in the root and the rest are divided up amongst their modularized area directories. Currently, I have the option of handling data migrations like so.

Question:

How would I rewrite each of my classes in the area folder's subdirectories to eliminate the individual migration calls?

Source:

Database Migration Commands Below

Establishing Migrations for Root Models

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

Establishing Migrations for each 'Areas' Model

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

Idealized Migrations

Enable-Migrations
Add-Migration Application
Update-Database

C# Classes Below

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; }
    }
}

End Note

Am I just being too lazy or picky? Isn't it more effective to run a single context? I am new to this, so my understanding of best practices are shaky at best.

Resources for Guidance

Code First Migration in Multiple DbContext

Inheritance in Entity Framework: Table per Hierarchy

ASP.Net Forums

Package Manager Console Commands - get-help Enable-Migrations -detailed & get-help Add-Migration -detailed & get-help Update-Database -detailed

Upvotes: 2

Views: 2755

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239290

Each unique context must be migrated separately. There's no way around that. If you only want to do a single migration, you must combine all the contexts into a single context. Personally, I'd recommend doing that, anyways. There's no need for multiple contexts to serve a single app, unless some of them are for connecting to existing databases. In which case, you wouldn't need to migrate them anyways.

UPDATE

I'm still not sure how I can merge all of this to create a single context.

On a basic level, your single context would just need to reference all the various area model namespaces:

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
}

However, it would be preferable to simply reorganize your project. Entity classes don't have to go into a "Models" directory and they don't have to be stored along with the area that uses them. Personally, if I'm doing a relatively straight-forward MVC app, I usually reserve the main "Models" directory in the project root for all entities the application uses along with a single context that references each.

For more complicated applications, I move this outside of the project completely and have all my entities and my context live in a class library. I then migrate against the class library and merely add it as a reference to the project(s) that need those entities.

No matter what you do, though having entities strewn all about between different areas is going to make maintenance a bloody nightmare, as you'll always need to remember what entity goes with which area, and god forbid there's even any bleedover where you begin to use the same entity in multiple different areas but it's only defined in one.

Upvotes: 2

Related Questions