search

vany0114 / EF.DbContextFactory

With EF.DbContextFactory you can resolve easily your DbContext dependencies in a safe way injecting a factory instead of an instance itself, enabling you to work in multi-thread contexts with Entity Framework or just work safest with DbContext following the Microsoft recommendations about the DbContext lifetime.
http://elvanydev.com/EF-DbContextFactory/
MIT License
93 stars 21 forks source link

Healthchecks support #17

Closed Inlustris closed 5 years ago

Inlustris commented 5 years ago

Hello vany0114,

We use the dbcontextfactory and would like to start using the EF 2.2 health checks. After starting with the health checks i encountered a problem. The healthcheck delivered in AspNet makes use of DbContext. And not the DbContextFactory we use.

Is it possible to create or implement the healthcheck of 2.2 in this package?

King regards Inlustris,

vany0114 commented 5 years ago

Hi @Inlustris

You're right, the HealthChecks.EntityFrameworkCore implementation expects a DbContext instance itself rather than a factory of a DbContext (Func<DbContext>) that's why you have that issue.

So, as I see this scenario, you could handle that using a custom healthcheck or even using the built-in healthcheck provided by Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore package.

I made a simple example in order to show you both approaches, I think both are correct, so you can create your custom healthcheck which receives a DbContext factory or you can use the built-in one, injecting a DbContext as an instance just for the health check purpose. At the end of the day, that instance only will be injected when the health check is executed and it's only for reading purposes, so you shouldn't have concurrency issues.

So, let me know if that helps.

PD: The idea to implement a healthcheck using DbContextFactory out of the box is great, let's see if more people request it, then we can package it!