Problem
There might be situations, when you need to seed some data with keeping the business logic in mind. Applying business logic and versioning of SQL migration scripts can be time-consuming. We should not forget about it would be great to be able to trace back the changes done in the database.
Examples
- * You got a legacy project with a db schema you know you will need to modify during your upcoming implementations. You also know that, you will need to move some data from one table to another by applying business logic to it just before the app starts up for the first time with the latest migrations.
- * You have a missing feature in your system, and you have a repetitive data manipulation (inject) task. For example, you need to modify user access controlled via db tables, because you do not have a UI, feature in the app to do so.
You also would like to apply the business logic regarding the User Access of the project and you also would like to be able to trace back who modified user data and when?
Solution
You can seed the data with using the existing business logic already composed in your solution and access it later in the IoC of your app. All you need to do is sipmly to register ISeed implementations to your ServiceCollection. Later on, you can see which seeds have been run via the sdr.SeederHistories table.
How to use?
- Register your
ISeed
implementations with theExtensions.RegisterDataSeeder<>
- Here goes your implementations of
ISeed
- Here goes your implementations of
- Register this project's tools and services via the
Extensions.RegisterDataSeederServices
- It is needed to use this project's tools
- Replace the
IHost.StartAsync
withExtensions.MigrateThenRunAsync
- It is needed to be able to run the
ISeed
withBeforeAppStart
option - It is needed to ensure the
SeederHistories
table got migrated
- It is needed to be able to run the
The example is from the AJProds.EFDataSeeder.Tests.Console
project
class Program
{
public const string CONNECTION_LOCAL_TEST =
@"Server=localhost\SQLEXPRESS;Initial Catalog=SeederTest;Trusted_Connection=True;MultipleActiveResultSets=true";
static async Task Main(string[] args)
{
await Host.CreateDefaultBuilder()
.ConfigureServices(ConfigureServices())
.Build()
.MigrateThenRunAsync(provider =>
// Ensure the TestDbContext's migration is run on start
provider.GetRequiredService<TestDbContext>()
.Database.MigrateAsync());
}
private static Action<IServiceCollection> ConfigureServices()
{
return collection =>
{
// Register seeders
collection.RegisterDataSeeder<AlwaysRunTestSeed>();
// My own, custom, test setup
collection.AddDbContext<TestDbContext>(builder => builder
.UseSqlServer(CONNECTION_LOCAL_TEST));
// EFSeeder setup - with an own EF Migration History table
collection.RegisterDataSeederServices(builder =>
{
builder
.UseSqlServer(CONNECTION_LOCAL_TEST);
});
};
}
/// <summary>
/// My custom seed, that will run after all app start
/// </summary>
public class AlwaysRunTestSeed: ISeed
{
private readonly TestDbContext _dbContext;
public int Priority => 50;
public string SeedName => "Always Run seed";
public SeedMode Mode => SeedMode.AfterAppStart;
public bool AlwaysRun => true;
public AlwaysRunTestSeed(TestDbContext dbContext)
{
_dbContext = dbContext;
}
public async Task SeedAsync()
{
_dbContext.Testees.Add(new Testee
{
Description = "Always Run seed"
});
await _dbContext.SaveChangesAsync();
}
}
}
You can define when the ISeed implementations should run:SeedMode.None
No ISeed logic will be run. You need to find the BaseSeederManager
in your ioc and run it with the SeedMode.None
argument.
var baseSeederManager = provider.GetRequiredService<BaseSeederManager>();
baseSeederManager.Seed(SeedMode.None);
SeedMode.BeforeAppStart
You must use the Extensions.MigrateThenRunAsync
with your HostBuilder
, because this procedure will not start up the host until all migration and seed (with SeedMode.BeforeAppStart
) has been run successfully.
await Host.CreateDefaultBuilder()
.ConfigureServices(ConfigureServices())
.Build()
.MigrateThenRunAsync();
SeedMode.AfterAppStart
After the host has started successfully, those ISeed
classes, that have been set to run AfterAppStart
will run in the background, in an IHostedService
.
ISeed.RunAlways => true
You can re-run the ISeed
procedures every time, when the application starts up. Simply set the RunAlways
property to true in your ISeed
implementation.
Comments
Post a Comment