Giters

dotnet-architecture / eShopOnContainers

Cross-platform .NET sample microservices and container based application that runs on Linux Windows and macOS. Powered by .NET 7, Docker Containers and Azure Kubernetes Services. Supports Visual Studio, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other code editor. Moved to https://github.com/dotnet/eShop.

Home Page:https://dot.net/architecture

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Business entities mutation and integration events: why are there multiple DbContexts?

marconato7 opened this issue · comments

commented

Hello! How are you?

Say we are talking about the Catalog microservice.

I am having a hard time wrapping my head around the fact that there are two DbContexts: IntegrationEventLogContext and CatalogContext.

Why is that? 🤔

Thanks.

commented

HI @kriubi, thanks for sharing your query here. The two DBContexts are used for different databases. One for IntegrationEventLogEntry and another for catalog data like Item, brand, and type. I hope it helps.

commented

I am closing this issue, however, feel free to continue the conversation in case of further queries

commented

Thanks for the reply, @erjain.

I don't think you are right, tho.

Take a look (branch 6.0.0):
image
image

IntegrationEventLogContext was deliberately made as a "building block" (shared code between microservices), but I still don't get it.

It feels like the decision to split entities between two contexts was made just to showcase this EF Core feature (as seen in CatalogIntegrationEventService.cs): https://learn.microsoft.com/en-us/ef/core/miscellaneous/connection-resiliency

Is there another reason why? Am I missing something?

Thanks again.

Also, will you reopen this issue? I'd like to continue the conversation 😁