How to deal with "fat" CrudCrontrollers?

[centerdevs]

Hi guys. Someone know any good example over GitHub where i can see Controller organizing with Backpack? Day by day my controllers with many "customs" get bigger. I think maybe to use some traits or some other simple solution.

[soufiene-slimi]

Hi @centerdevs, check this article, it may help you.

https://dzone.com/articles/practical-php-patterns/practical-php-patterns-service

[centerdevs]

Thank you, i already use service layer in my projects. But with Backpack I'm little confused because we have $this->crud object, which we use to operate with all Backpack services, so i'm looking for some good ideas how to separate it for some logical chunks.

[centerdevs]

Let's see on example from Backpack Demo project.

https://github.com/Laravel-Backpack/demo/blob/master/app/Http/Controllers/Admin/MonsterCrudController.php

I have something like this, how to split it with less effort?

[tabacitu]

Personally, whenever a Controller gets to big, this is what I ask myself and do:

1) Can some of the logic be shortened? Aka is it too verbose?
=> rewrite the addField() statements to Fluent Fields
=> rewrite addColumn() to Fluent Columns
=> rewrite addFilter to Fluent Filters
(usually this makes the controller 3-4x shorter)

2) Can some of the logic be reused somewhere else? Aka is there duplication?
=> Custom Operations / Custom Traits

3) Do I have custom operations? Methods that do not overwrite Create/Update/List, but do something else?
=> Custom Operation, even if it's only used on one CRUD, because it's ridiculously easy to create one;

4) Are there bits of logic that are not that used/important most of the time?
=> traits, for example MonsterCrudFilters with only one method addMonsterFilters()

5) Are there A BUNCH of fields/columns, which are naturally split somehow for the user (ex: into tabs)? Because if there are too many fields for the dev, there are DEFINITELY too many fields for the user, so they should be split somehow.
=> traits, for example MonsterCrudFields with three methods addMonsterFieldsForFirstTab(), addMonsterFieldsForDetailsTab(), addMonsterFieldsForRelationshipsTab()

Personally I prefer using the simplest solution available to "trim the fat" inside controllers. And I found the simplest solution of all is rewrite/refactor. The second simplest solution is hiding it in a trait. Some won't like that, they'll see traits as just "hiding it under the rug". Which is true, I guess. But so is anything else - any design pattern you might choose just "hides it under a rug", but most of the time it just hides it under a more expensive rug. So most of the time I choose the cheap rug - the trait 😀 So does Laravel in A LOT of cases.

Hope it helps!

[centerdevs]

Awesome post! I'm sure it will be useful for many people here. Fluent style is cool and i will start refactoring with it.