4 ms·
Looking at this, it has similar aspects as ASP.NET Core, and the same flaws as the Controller per class design used. Methods such as "index", "show" and "store"
by Ciantic 2y ago
Looking at this, it has similar aspects as ASP.NET Core, and the same flaws as the Controller per class design used. Methods such as "index", "show" and "store" do not share a state, they shouldn't share a class either.
However, you can rectify this, by just not trying to share a class with any of those. In .NET Steve Smith, aka Ardalis shows how to do this with his Clean architecture [1]. One idea is to make a class for each endpoint. This also makes it easier for "Update" classes to share functionality with other "Update" classes and so on.
[1]: https://github.com/ardalis/CleanArchitecture/tree/main/sample/src/NimblePros.SampleToDo.Web/Projects https://github.com/ardalis/CleanArchitecture/tree/main/sampl...
- treve 2y agoGrouping related functionality in a class and using it as a namespace, and using inheritance to get a few useful common features in close proximity and handing hooks is perhaps not the most correct from an OOP perspective, but it's common and results in much less boilerplate than doing everything 'correctly'. What's more egregious to me is that the methods should just match HTTP method names and have 1 controller per route.
- mewpmewp2 2y agoWhat about just having request handling functions in a single file or a directory?
- crowcroft 2y agoBoth approaches are fine, and doable. As a convention I don't think one method per verb in a controller is inherently bad just because they don't share state. Plenty of long running, maintainable projects follow this practice.
- OptionOfT 2y agoThe idea was that a controller is instantiated per request, so constructor and then your method, index / post / list / ... You could use your constructor as a shared place to set up the requirements for your method.