HealthCheck
HealthCheck copied to clipboard
fjeldstad
New modules + refactoring
- HealthCheck.Mvc module: convenient extension with ready to use controller, view for healthcheck page for your MVC application easy configurable and injectable into main application by several lines of code.
- HealthCheck.WebApi module: convenient extension with ready to use controller producing json result for your WebApi application easy configurable and injectable into main application by several lines of code.
- HealthCheckResult is now in failed state if no checks spotted
- Configurators added
- CheckerBase was changed. Properties converted to constructor parameters to encourage using of IoC.
@Hihaj thx for response.
The goal behind refactoring is making namespaces self explanatory and typical. It's common practice that extension classes are located in Extension folder and sub namespace eventually. Ofc when developing project further we should think about compatibility but i suppose that we should not hesitate to improve existing codebase. Thx nuget helps us moving forward with letter versions of packages and preserving existing versions.
As for C# type aliases i use class names instead of keywords deliberately on my opinion it makes code more consistent and allows to avoid confusion with changing of meaning of certain keywords in next versions of dotnet. Still i wont argue about it and will fix it back as you asking.
As for check result - well i am eager to use IoC and polymorphism as much as i can. In future we can have different types of ICheckResults. For instance HealthCheckResult i thought must be ICheckResult, maybe future SectionChecks could also implement this interface. I agree that it is supposed to be just a DTO and thus it should not have any behavior => interface
