Home/ Questions/Q 3396600
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T04:25:38+00:00

This is a question with no real problem behind, just a product of my

  • 0

This is a question with no real problem behind, just a product of my sick mind and drive to make things slightly weird 🙂

So, I have this PHP application build on top of my own MVC oriented framework (yes, I did my own instead of using existing one). And it is done by the book so we have model (data and database manipulation), view (templates filled with data and rendering output) and controller (handles requests, gets appropriate data from model, puts data into view). Classic and boring scenario with request routing done with .htaccess rules.

Yesterday I did some changes in my code, bug fixes, couple improvements, etc. And I felt strong urge to rearrange the code of controllers. They feel somewhat heavy and bloated and number of methods makes it hard to navigate through the file, and such stuff. I’m sure everybody knows what I’m talking about.

I’m thinking about breaking my controller class into many classes, each one handling only one type of request like login or register or showProfile or killMe.

Now controller class has public methods corresponding to parts of user friendly (or maybe SEO friendly) urls and routing class invokes proper controller and it’s method according to url content.

Change I’m thinking about would shift a little routing mechanism into invoking specific controller and it’s Execute() method.

For example, for url = “www.example.com/users/login”
now it looks like that:

$controller = new url[0]();
$method = url[1];
echo $controller->$method();

and now url would change to “www.example.com/login” and routing code would look like that:

$controller = new url[0]();
controller->Execute();

I omitted parts where I parse urls and extract routing info from them as it is irrelevant to my question.

What benefits I see in that change?

  • one dedicated class per one request
  • smaller files
  • smaller code
  • easier maintenance
  • limited danger of breaking working controller when adding new features(new types of request) or fixing bugs

Disadvantages?

  • possibly a lot of classes
  • possible performance hit
  • ???

And my question is about what do you think about that idea and does it make any sense at all. And of course I’m more interested why I shouldn’t do it than why I should. So if you can think of any reasons why that would be terrible idea and abomination please speak now before it will be too late 🙂

EDITED
Clarification of a question:

I’m asking whether I should break my single big controller which handles many types of requests by it’s methods into many small controllers each of them handling only single type of request.

Now I have controller Users which handles requests like “login”, “showLoginForm”, “register”, “activate”, etc. Refactored code would consist of separate controllers for each of these requests.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A disadvantage I can think of for both the old and new methods is that you are mapping urls directly to class names. If you’d like to change the url you’d have to change the class name. If you’d like to have different urls for different languages, you’ll have to add a layer that will map urls to class names anyways.
    This is why I’d rather have a routing class that will map urls to class names which provides you a seam to change things.

    • 0