I know this isn't stackoverflow, but here goes.

I am developing projects in php, mostly Laravel atm, but as the project grows the project gets messy.

My code works, but I get confused if methods I do belong to a controller, if I should put them in a separate class and so on.

I am currently subscribed to Laracasts which seems to cover a bit of this, but do you guys know of some good ressources?

@lotd @yarwest

Depends.
We would probably need to see your code and what you want to accomplish to be able to help..

For resources, well.. Design patterns and best practices..
Perhaps look up how others have solved something similar to :)

Check Taylor Otwell & Adam Wathan on Twitter, they frequently tweet useful links :)

As a rule of thumb, you can try to keep controllers to max 1-2 extra methods outside of the conventional resource routes :)
- that's my preference of course. :)

Laracasts is a great resource and laravel is awesome. We switched to laravel for all new PHP projects a while ago. We even tried a few different content management systems based on laravel. We finally landed on PyroCMS, the documentation can still be improved but once you get the hang of it, you will notice it really encourages you to structure your code according to the design patterns (repository, presenter, observer, ...). PyroCMS might not be for everyone but you should definitely check it out. There's a slack channel for quick support among devs!

Also, controllers should be thin! All logic should happen somewhere else, be it a service or repository. My controllers usually have 4 lines per method, and the methods are mostly just index, create, edit, delete. A class should have one purpose and one purpose only. Read the book 'programming design patterns' by O'Reilly, it's funny and really really good and applies to most programming languages

Oh yeah. SOLID & KISS principles.
Those are great to have in mind.

The best way to remember for MVCs or similar...

View: Only display vars and very basic conditional logic
Controller: I only use controllers to do VERY basic tasks. All a controller is, is a middle man between your view and service...
Service: Logic goes here... this does not directly talk to the view and does not care about anything other than itself. Also note that there should be no html... try to keep to structs, arrays, booleans, queries, etc

I don't use Laravel but Symfony, but the idea should be the same.
For me, controllers are ONLY to handle HTTP/HTML stuff (is this GET or POST, build form, render view...).
For the business logic, the controller call one (and only one) method of the unit-of-work layer, which itself call several methods of the business layer, which itself can call entity and repository layer.
It's an extension of the MVC using 5 layers instead of 3: model-business-unit of work-controller-view.
It works very well for me, very solid architecture!

Great responses from our community! You are right - we are the improved SO. 😀

Seems interesting, still downvoting for stackoverflow exception though

Most of the stuff that I would say has been said here already :)
I would say that the service layer is the way to go. SOLID is a pretty good thing to live by.

@Charmgoggles don't be like that, he is free to ask a question if he wants to

I would maybe just add that wording can be a bit of a bitch allowing a person to not be able to associate it with known concept. As mentioned above the view, controller definitions are all good so this is more when those really clicked for me. Controller just directs actions, get me this or update that. When they say service just think class and when you think class think job description. Need to manage user data? Start with a single class whose job is to do this. In the end i think it all about categorizing if you can do that well, things fall in place. Kind of.

Thanks for the response guys, very helpful - I Will make sure to read up on solid principles and the Oreily book suggested