PixxelKick
React + .Net core api issue
Just add logging at any critical points of logic where a delay might happen in the flow of logic, reproduce the problem, and then inspect the logs for where the sudden slowdown occurs
The database is SQL Server, but we've ruled out the database itself as the primary cause, as it works quickly from my development environment.Is it that exact same database that the "prod" app points at? Or is it a seperate "dev" DB you tested against? Its critical to be 100% sure you verify the behavior against the exact same database too Id recommend, as always, start with fixing your logging. 99% of debugging production issues is getting your logs to be sufficient to show where the issue happens.
16 replies
Question regarding multiple calls to AddHttpClient()
Your business layer shouldn't be aware of the service collection at all really. That's an application layer concern.
Business layer really should just be defining all your services and not worrying about how the services get their dependencies.
Application layer actually handles sewing it all together with DI and running it
11 replies
Help with EF Core polymorphic associations
Do you actually have any need at all to display these audit logs in the application itself?
If not, I'd just slap an enum on the column to discriminate but I wouldn't put any traversal properties on it. It'd be a write only table as far as EF core is concerned.
Reading audit logs I usually leave to an admin with DB access unless the client explicitly requests the audit logs are exposed to the FE on some kind of admin page.
7 replies
Overkill on the use of interfaces for Dependency Injection in Web APIs?
Only way that can happen is if you put a static field or static prop on the class for some reason.
If you keep them readonly to just serve as effectively constant values though, it's still stateless really.
Only if you did something weird like put a static list on the class that you kept adding stuff to would it be a problem
15 replies
Overkill on the use of interfaces for Dependency Injection in Web APIs?
Note how
FooCalculationService has no dependencies and is atomic. It merely takes in a plain ole Foo and does its logic.
This is now very easy to unit test. No mocking needed, no dependencies, pure behavior, no side effects.
It does it's atomic job and returns a value you can easily assert on.
Meanwhile FooRepository depends on your db context and mostly just holds the logic for doing database stuff abd connecting to the Egress (ef core sql stuff)15 replies
Overkill on the use of interfaces for Dependency Injection in Web APIs?
Some people don't like this but it's served me very well. It reduces clutter, is less crud to maintain, and reduces inversion of control.
1. I don't make a service stateful unless I must, and even then I abstract out the stateful part to its own service and keep as much stateless logic in the static class as possible.
2. I don't add abstraction on top of the stateful service unless I need to mock it because it is "on the edge"
15 replies
Overkill on the use of interfaces for Dependency Injection in Web APIs?
My rule of thumb is to only use DI for services that are stateful, or are involved in statefulness.
Examples include:
- Object pooling
- HttpClientFactory stuff
- Entity Franework DbContext
- Configuration
- Logging
- Caching
Etc, these various services actually are stateful in some way.
For the vast majority of my logic I just use static classes and static methods. There's zero reason to use DI on a stateless singleton service, you just re-invented a static class when you do that.
15 replies