Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Darkdawg's avatar

Where should I put heavy code/logic for routes?

I'm new to Laravel and I don't have much experience yet.

So I have a few PHP scripts that I want to include in my website, and I like to think of them as tools. For example an image conversion script, that can take an input image and convert it to WebP & AVIF (just as an example). The script could be around 100-200 lines of code.

I tried creating a route which returned a view, which included the script file. A very simple approach, but probably not a good way of doing it?

So instead I created a ToolController, and defined a route for /tools (listing all tools) and one for /tools/{toolName} (showing a specific tool). This seems like a logical approach to me. A method within it checks which tool is requested, and returns the correct view for it. However, I'm pretty sure I'm not supposed to put a thousand lines of tool logic within the controller?

And then I saw someone mention services, where you should put the logic itself. But I'm not sure if I understand it correctly, so I'm asking for help in getting on the right path.

Say I have 3 tools (ToolA, ToolB & ToolC), should I:

  1. Define a route for /tools: Route::get('/tools', [ToolController::class, 'index'])
  2. Define a route for /tools/{toolName}: Route::get('/tools/{tool}', [ToolController::class, 'show'])
  3. Create a separte service per tool: ToolAService, ToolBService, ToolCService
  4. Create a separte method within ToolController per tool, which the show method runs

Feels like a lot of work, but if it's a proper way of doing it, then I don't mind. Any help is appreciated!

0 likes
6 replies
tykus's avatar

I tried creating a route which returned a view, which included the script file. A very simple approach, but probably not a good way of doing it?

No. Think in terms of classes and objects, rather than a script included on a view.

However, I'm pretty sure I'm not supposed to put a thousand lines of tool logic within the controller?

It would seem that there would be opportunities to refactor this logic into discrete methods; but without sight of the actual code, impossible to say. Generally, any logic that has side-effects should not be GET requests - GET requests typically are considered safe, i.e. they are read-only, leaving the Resource unchanged after being executed.

Feels like a lot of work, but if it's a proper way of doing it

What feels now like a lot of work now can become a maintenance nightmare in future! Invest the time to do it right now if you can. Check out the series here such as Whip Monsterous Code into Shape and Write Code that's easy to maintain here on Laracasts for some strategies to extract logic into discrete classes and methods.

Lastly, there are a wealth of packages (e.g. Spatie's Media-Library, Intervention Image) already written for image processing, perhaps utilising these battle-tested alternatives could work for you?

Darkdawg's avatar

@tykus Yeah the WebP/AVIF was merely an example. For the sake of it, let's pretend the tools are unique.

If refactoring into discrete methods was an option, would you put those in the controller? A service would be a step too many?

tykus's avatar

@Darkdawg

If refactoring into discrete methods was an option, would you put those in the controller

No, better to create a class (or set of classes) with, as much as possible, clearly defined responsibilities. This is not trivial if you are not used to Object-Oriented Programming, but you can get there by degrees!

I should add... there are many, many ways to solve your issue; solutions can be anywhere on a spectrum of simple to complex.

Darkdawg's avatar

@tykus Yeah OOP doesn't sit just yet, but I'm trying to get there.

Okay, but where would you put that class/those classes? Would you create a related folder like app/Tools and put the classes there, and use them within the controller? Do classes like that have a specific term/name in the world of MVC/Laravel? Is that the same as Service classes?

tykus's avatar
tykus
1 year ago
Best Answer
Level 104

@Darkdawg

Yeah OOP doesn't sit just yet, but I'm trying to get there.

For a start, make a class. Put all of the existing logic in an entry method, e.g. handle. Then looking at all of that logic, see if there are lines that can be grouped into methods describing a step in your process, so the handle method begins to look like a series of steps in a methodology. Opportunities to isolate the logic further into separate classes might be a step too far for now, but should be the ultimate goal. Again, looking at the Whip Monsterous Code into Shape and Write Code That's Easy To Maintain series linked above for practical implementation of this strategy!

Would you create a related folder like app/Tools and put the classes there

Yes, that would be a good start.

Do classes like that have a specific term/name in the world of MVC/Laravel?

Tools is a good namespace if that makes sense to you as the developer. If there is something else that groups the tools as a set of functionality, then add that as well if it makes sense to you. IMHO, Services is an abused terms for I didn't know what else to call this, so I called it Services!

Darkdawg's avatar

@tykus Thanks for taking your time, this helps a lot! I'll have a look at those videos as well!

Please or to participate in this conversation.