I’m developing an intranet application and I’m trying to use some concepts from Domain Driven Design (DDD) and Command and Query Responsibility Segregation (CQRS) in .NET Core, with EFCore.
But, to avoid weird exceptions from the API, on every Command and on every Query I’m first checking if the database is online (using DbContext.CanConnect()) and I send a pretty message to the user in case it’s not. Instead of throwing some EF exception saying the database could not be found. I’m using a generic
ApiResponse<T> that has
.ErrorMessages to always return the same way from the API.
Is it the recommended approach? Or should I catch the exception somewhere else and return the message to the user from this other place? Or should I actually throw the exception from the API?
Elaborating a bit on my ideas: I’m thinking of using a .net Core Middleware to avoid this repetition and check the database prior to even getting to the Command/Query handler. Is it a good solution to the repetition?
EDIT: I realize there seems to be multiple questions in here, but my main concern is:
What’s the DDD+CQRS recommended approach for this scenario where I’m repeating the same code (to check if DB is online) on every Command and on every Query?