I am doing just this (what you said at the end) - heavy business logic into the action classes, everything else not that heavy goes to the regular controller. Few months later I came back to revisit a project and instantly got familiar with (the one using this approach). The application was medium size project for assets & packages with a unique feature of uploading csv to populate records. I have found that colleagues in my company like to go even on small apps with 3 different patterns mixed together and they would copy paste someone's mess and re use it over and over... So guys please think before you act, just ask yourself is this even gonna be used ever? Matt Stauffer had a great talk on Laracon 2022 about abstracting too early, highly recommended! Anyway excellent video Andrew, keep up the good work!
abstracting too early comes, for some, with experience there are people 10 years+ that abstract it because they read something somewhere without understanding why and there are others that recognize certain things from the start of the project and extrat those
I like the way you named your controllers here. I've recently started using Single Action Controllers, but I've been trying to use the RESTFUL naming convention, eg PostsIndexController, PostDeleteController etc, but yours is much more readable and clear as to what it does.
I have to disagree here, I think Posts/CreateNewPostsController has no valuable information over Posts/CreateController or even Posts/CreateNewController. Why namespace controllers if you repeat the namespace in the controller name? Sure, in the routes file, CreateNewPostsController::class looks nice, but so does Posts/CreateController::class
I have recently started using htmx with laravel. I use these single action controllers to process the rerendering of some component, like a search results filter.
single use controllers are nice as long as you don't want to have certain things shared, like a project specific way of logging data fro trasability purposes, queries, caching I personally prefer to: - move my validation to request classes - move my business logic either to a repository (either just quesries or multiple part execution)/action/service class - move common things like: http calls, data remaping, caching, etc to a lib/herper class - don't add the model to parameters in controllers and move the logic to somewhere i can query it (with eager loading or joins etc) with the ID as a parameter, mostly because in certain cases i want to add conditions directly in the sql query and early break the code execution if they aren't meet, instead of doing a query/multiple and check it in the code
18 дней назад
Can't you extend parent controller or use a trait?
серьезно? в 2023 году об этом кто-то не знает еще? тема не раскрыта, зачем это нужно? это называется контроллер одного действия, зачем для CRUD использовать такой контроллер? думал что то новое покажите
