Closed Niisc closed 2 years ago
Good job Really well written! I'm not sold about the own controller/Service/Repo. Repo I understand because it has its own database entry. Service and Controller could be put under User imo.
Hmm, imo its more organized like this @chrisK00 opinions?
Good job Really well written! I'm not sold about the own controller/Service/Repo. Repo I understand because it has its own database entry. Service and Controller could be put under User imo.
Hmm, imo its more organized like this @chrisK00 opinions?
Splitting up the responsibilites is important to follow SRP and provides more decoupling, easier classes to navigate. If we dont do something like this we need to switch over to MediatR. This approach also doesnt break OCP
We shouldnt stick all our logic in one class, and the responsibilites are a bit different. If we want to have more features regarding our jokes, we wouldnt put them in the jokes controller because we would run in to a OverFlowException (bad joke)
So if we think about our consumers they get jokes on api/jokes but to get saved jokes they get them on api/savedjokes - i think this is totally fine but the alternative is to simply extend the jokes controller. So the route would become api/jokes/saved which is a bit easier to keep track on but at the same time we still split up the classes.
The important part is that we dont nest to much because that will cause a very ugly url, but in this case i cannot see what else we would nest after the saved.
Good job Really well written! I'm not sold about the own controller/Service/Repo. Repo I understand because it has its own database entry. Service and Controller could be put under User imo.
Hmm, imo its more organized like this @chrisK00 opinions?
Splitting up the responsibilites is important to follow SRP and provides more decoupling, easier classes to navigate. If we dont do something like this we need to switch over to MediatR. This approach also doesnt break OCP
We shouldnt stick all our logic in one class, and the responsibilites are a bit different. If we want to have more features regarding our jokes, we wouldnt put them in the jokes controller because we would run in to a OverFlowException (bad joke)
So if we think about our consumers they get jokes on api/jokes but to get saved jokes they get them on api/savedjokes - i think this is totally fine but the alternative is to simply extend the jokes controller. So the route would become api/jokes/saved which is a bit easier to keep track on but at the same time we still split up the classes.
The important part is that we dont nest to much because that will cause a very ugly url, but in this case i cannot see what else we would nest after the saved.
Thank you for the great explanation! This is where I need to learn.
You have some conflicts to resolve too. Please Pull dev and resolve them.