C#•2w ago

"Correct" way of setting up DB for Aspire.NET MicroServices following CA

I have an Aspire.NET Project that has key services separated as MicroServices which each follow the Clean Architecture. See below an example structure:

MarketService/API
MarketService/Services
MarketService/Data

CartService/API
CartService/Services
CartService/Data

UserService/API
UserService/Services
UserService/Data

MarketService/API
MarketService/Services
MarketService/Data

CartService/API
CartService/Services
CartService/Data

UserService/API
UserService/Services
UserService/Data

The Data for each has the DTO's and the DbContexts, My problem arises where I need Migrations or to Ensure the DB is created, is there a best practice? I found an aspire-sample from Microsoft but this only has 1 DBContext where they have a separate project for it and they use A separate 'MigrationService' to handle it. I'm thinking that might be it but have no idea how to set it up with multiple DBContexts, if that's even the right idea.

GitHub

aspire-samples/samples/DatabaseMigrations at main · dotnet/aspire-s...

Contribute to dotnet/aspire-samples development by creating an account on GitHub.

8 Replies

QuantixOP•2w ago

The GPT is telling me to have 1 DatabaseInitializer that takes in multiple DbContexts and loops through them running EnsureCreated

public class DatabaseInitializer
{
    private readonly IEnumerable<DbContext> _dbContexts;

    public DatabaseInitializer(IEnumerable<DbContext> dbContexts)
    {
        _dbContexts = dbContexts;
    }

    public void Initialize()
    {
        foreach (var context in _dbContexts)
        {
            // Ensure the database is created
            context.Database.EnsureCreated();

            // Apply migrations
            context.Database.Migrate();
        }
    }
}

public class DatabaseInitializer
{
    private readonly IEnumerable<DbContext> _dbContexts;

    public DatabaseInitializer(IEnumerable<DbContext> dbContexts)
    {
        _dbContexts = dbContexts;
    }

    public void Initialize()
    {
        foreach (var context in _dbContexts)
        {
            // Ensure the database is created
            context.Database.EnsureCreated();

            // Apply migrations
            context.Database.Migrate();
        }
    }
}

can't tell if it's trying to gaslight me but maybe it's alright? I'd get running migrate on each one but not EnsureCreated, surely that only needs to be once i don't think i'd set it up like GPT told me but rather like how the aspire sample works

Tvde1•2w ago

Each microservice should be responsible for its own database, so there shouldn't be a microservice initializing the other databases

QuantixOP•2w ago

They all share the same DB are you saying I should make individual dbs for each?

Unknown User•2w ago

Message Not Public

QuantixOP•2w ago

i'm quite new to all these structures but I know they're quite opinionated so i'd like to hear how you'd set it up i believe the main appeal of micro services is redundency so that if one goes down the others remain up but is that actually viable? It'll be quite a big solution so for k8s for example u can have these micro services across multiple regions auto restart i suppose I could have one big asp.net project for each of the services is that what you would do? but in terms of the db thing say you had MarketService you'd have a MarketService db on the same db server like postgres is there any documentation on this

Rory•2w ago

I feel the thing about "microservices" is it's a bit of a loaded term now and a bit of a fuzzy definition, so it can be useless to use the term sometimes when saying "I'm doing microservices!" rather than highlighting what you're trying to achieve But yeah, typically a microservices-oriented architecture is about breaking down the composition of your service into smaller ones with discrete roles and, crucially, those services having complete isolation of their own data, and only communicating with other services through intentionally designed APIs (http, messaging, whatever). You might have different teams owning different services, even writing them with different technologies. Redundancy is one appeal (in the sense you describe and also not bringing the whole application down if one whole area (all instances of CartService for e.g.) goes down). There's other appeals like making a system "easier" to understand, develop, deploy, refactor. Not sure I'd call any "main" The key thing for you here would be ensuring MarketService can't directly interact with CartService's database tables and that they only share data over APIs. You would want a logically separate database to enforce this ideally I'd think. They could be the same server initially but you risk bringing both down if that goes down (if this is just for practice though don't complicate your life - keep the databases separate but on same server)

glhays•2w ago

Agreed. https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview#orchestration

.NET Aspire overview - .NET Aspire

Learn about .NET Aspire, an application stack designed to improve the experience of building cloud-native applications.

QuantixOP•2w ago

thank you for the advice!

Gaming

Programming

"Correct" way of setting up DB for Aspire.NET MicroServices following CA

Did you find this page helpful?