Timeline for Why is it so common to use the dbContext directly in the controller in a WebApi application?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 3, 2024 at 15:46 | vote | accept | Álvaro García | ||
| Sep 2, 2024 at 22:33 | comment | added | Greg Burghardt | + so many up votes for simplifying and removing layers when transitioning to micro or web services. You already have the 7-layer OSI network model in between services. How many layers does a person really need? | |
| Sep 2, 2024 at 20:46 | comment | added | Ewan | If you have a large monolith style program or desktop app, then you can see how layer separation and interface segregation help you with refactoring. But only because each layer does multiple things. With the case of most REST APIs a single controller method is called, does one thing and then exits. If you need to change that thing you can just change it. Extra layers dont help | |
| Sep 2, 2024 at 18:42 | comment | added | user1937198 | @ÁlvaroGarcía As for projections, a certain level of complexity in a controller is not a bad thing. Either buisness logic or data access. But you don't usually want both. So if you don't have much buisness logic then more complex data access becomes viable. If you have non-trivial data access and non-trivial buisness logic in a non-trivial number of your endpoints, thats when you are starting to get into 'more complex projects'. | |
| Sep 2, 2024 at 18:38 | comment | added | user1937198 | @ÁlvaroGarcía Consider how much work it would be to update the repository, vs update the controllers. Just because you have a repository doesn't mean you magically don't have to update anything. If you haven't significantly decreased the total amount of change, and change is unlikely (EF core is mostly backwards compatible, baring swapping out the ORM completely), then you aren't actually likely to save much work overall, even if you reduce the change needed to the controllers. And that isn't worth the upfront cost. | |
| Sep 2, 2024 at 17:20 | comment | added | Álvaro García | And a second question. If I would like to use projections for example, or another more advanced feature of EF, that it is possible to need also in small projects. All this code, would it have to be implemented in the controller? If this is the case, the controller becomes more complex. | |
| Sep 2, 2024 at 17:16 | comment | added | Álvaro García | Thanks for the answer. I understand for small projects it could be over engineering, but if in the future I want to update to a new version of entity core, that perhaps changes methods, or change behaviour of some methods, that has passed in the past. Wouldn't it too much work change the code of all controllers and check if it works? If I implement a new repository that I test that it works as the controllers expect, wouldn't it better? | |
| Sep 2, 2024 at 16:28 | history | edited | Ewan | CC BY-SA 4.0 |
added 550 characters in body
|
| Sep 2, 2024 at 16:18 | history | answered | Ewan | CC BY-SA 4.0 |