Reputation: 10459
Is it possible to split (not moved to single class library project) migrations to several .NET Core class libraries?
I am following architecture design for splitting application to several independent modules. (Source)
But I having problems splitting migrations to several projects. Is this supported?
In startup I load dll files in specific folders. In DbContext.OnModelCreating
I register all types loaded from loaded dll files and register entities.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
List<Type> typeToRegisters = new List<Type>();
foreach (var module in GlobalConfiguration.Modules)
{
typeToRegisters.AddRange(module.Assembly.DefinedTypes.Select(t => t.AsType()));
}
RegisterEntities(modelBuilder, typeToRegisters);
base.OnModelCreating(modelBuilder);
RegisterCustomMappings(modelBuilder, typeToRegisters);
}
private static void RegisterEntities(ModelBuilder modelBuilder, IEnumerable<Type> typeToRegisters)
{
var entityTypes = typeToRegisters.Where(x => x.GetTypeInfo().IsSubclassOf(typeof(EntityBase)) && !x.GetTypeInfo().IsAbstract);
foreach (var type in entityTypes)
{
modelBuilder.Entity(type);
}
}
private static void RegisterCustomMappings(ModelBuilder modelBuilder, IEnumerable<Type> typeToRegisters)
{
var customModelBuilderTypes = typeToRegisters.Where(x => typeof(ICustomModelBuilder).IsAssignableFrom(x));
foreach (var builderType in customModelBuilderTypes)
{
if (builderType != null && builderType != typeof(ICustomModelBuilder))
{
var builder = (ICustomModelBuilder)Activator.CreateInstance(builderType);
builder.Build(modelBuilder);
}
}
}
But I don't how migrations are executed with context.Database.Migrate();
Idea is that tables are not created/updated if ASP.NET Core deployment doesn't include specific module. If at any point in the future, customer buys module D, I just send them dll. The next startup context.Database.Migrate();
would create all tables and apply migrations for that module.
Additional example:
Idea is to split application to modules. Let's say module A, B and C. Customer 1 buys module A and B and customer 2 buys module A and C.
There is no point that tables for module C are created for customer 1, and tables for module B for customer 2.
At some point in the future, customer 1 buys module C (they receive dll for module C). Now tables should create and all migrations for module C.
As far as I know migrations could be dedicated to specific project. Link. The only problem I see is the ContextModelShapshot
.
Upvotes: 4
Views: 4881
Reputation: 30345
All the Migration
classes for a given DbContext
need to be in the same assembly. To split them across different assemblies, you'll need separate DbContext
classes.
You may find the Using a Separate EF Core Migrations Project doc page interesting.
Upvotes: 3