Code structure behind controller

Published 11 months ago by rikw

Hi all,

Please assist me with some guidance on structuring my code behind controllers. I try to only use resource controllers. This works well and makes for a clear structure. Now the controllers of course need to collect data and dispatch actions. But how do I structure this?

Example... We need data from an external API (Toggl). This is data about work logs on projects. This data needs to be transformed to fit our needs for a .csv file to import into another tool.

I created a ToggleApiService class to connect to Toggl and call certain endpoints and collect data. My controller now transforms the data to output a csv. This gives quite some code. What would be a good naming scheme/logic to seperate the tranformation from the controller?

Of course this is an example use case. Basically, how do you keep controllers as short as possible and put the logic somewhere else, which aren't models.

Thanks for your thoughts!


@rikw Sounds like a text book example of the use case for Repositories.

11 months ago (135,830 XP)

Don't fry your brain over this .... If and only if, your functions (so called logic) will be re-used by from multiple locations, you can move it to services/facades or static util classes ...

Its perfectly OK to have a few helper functions within controllers, if they are only to be used by the controller in question ...


@goatshark In my perception repositories are in the middle of data/models and the application to provide flexibility in the future.

@d3xt3r Thanks for your straight forward approach. This is non reusable code and only serves this function. Utility might be a good one too. I think this is the same as Helpers (I'm from the Magento world).

Please sign in or create an account to participate in this conversation.