M
M
merlin-vrn2013-08-03 11:29:27
symfony
merlin-vrn, 2013-08-03 11:29:27

Why do developers so categorically claim that one front controller is better?

So, a quote from the documentation. They approve:

A much better solution is to use a front controller: a single PHP file that handles every request coming into your application.

Arguing this by the fact that each file must perform the same actions for initialization: include libraries, and so on:
There are several problems with this approach, including the inflexibility of the URLs (what if you wanted to change blog.php to news.php without breaking all of your links?) and the fact that each file must manually include some set of core files so that security, database connections and the "look" of the site can remain consistent.

Half a page later, they suggest using mod_rewrite to decorate urls:
Using Apache's mod_rewrite (or equivalent with other web servers), the URLs can easily be cleaned up to be just /, /contact and /blog.

So, it is proposed to collapse different paths into one, and then again, already in PHP, distinguish them and process them differently.
But I could make three files /index.php, /contact/index.php and /blog/index.php and get the same thing, but compared to the Symfony approach, I:
  • I would dump all the routing on the web server - I wouldn’t have to do it in PHP at all, in addition it would become faster
  • I would not set up a rewriter, which is inconvenient to set up, in addition, it also does not add speed
  • could easily skip optional steps for individual entry points, for example, parsing the query parameter string for static pages, without unnecessary conditional structures
  • individual modules, presented in this case as separate entry points, would be less connected, which means that the mutual influence is less, it is easier to adapt, update, etc.
    this is what I figured offhand.
    That is, I use more of the long-tested and simpler code, but in general I get the same thing.
    At the same time, flexibility is not reduced. It makes no difference how I set up the URLs: I add magic lines in the magic file, or I create directories and put magic files in them. If I need to change the urls so that the old ones work, no one bothers me to use a rewriter to solve this abnormal task.
    Regarding the “same initialization”, I also disagree with the arguments: in these unified controllers of yours, you still have to use magic like “including libraries, parsing a request, outputting a response”. How is this different from the "enable standard initialization" line in individual entry points?
    I think the question is actually not just about Symfony - everyone does it - from Joomla to Dokuwiki. Explain why this single front controller is so much better that people use it despite the obvious advantages of separate entry points?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
N
Nikolai Vasilchuk, 2013-08-03
@Anonym

With one entry point, you don't have to worry about routing at all. You add a new route to the config and wrap it to the desired controller. Everything. With proper autoloading, you don't have to worry about what classes are needed for this particular controller. When the number of routes approaches a hundred, you begin to understand that this is much easier.

N
Nazar Mokrinsky, 2013-08-03
@nazarpc

/blog looks nicer than /blog/index.php and hides implementation details + there is also dynamic routing, when you may not know in advance which URL will come, and you will first have to search in the database or somewhere else.

O
OnYourLips, 2013-08-03
@OnYourLips

It's easier to do routing on the application side than half on the application side and half on the webserver side.
You won't be able to completely do routing on the web server side if you need complex logic.
Moreover, the server may not have the same web server under which you write the rules: for example, you write under nginx, and the admins suggest using Apache.

U
UZER2006, 2013-08-03
@UZER2006

As for me, the issue is debatable. Your arguments are valid, but here's what I think.
1. Concerning a statics. If static is really static, then it should be given completely separately. If the engine still participates in it, this is no longer static.
2. Well, the very essence. I don’t know why, but somehow it’s even more aesthetically pleasing and beautiful for me when the project has one entry point, and not several in different places. I agree that initialization can be included in a separate file. But it’s either to start each file by connecting an init file (as for me, aesthetically ugly)), or also remember which file is the entry point and which is not. Nothing to say about relative addressing within the file system.
At one time in my project I used something like this. There is one entry point. The url is passed the module, action and any additional parameters. App is initialized, parses request and passes control to the required class with all other parameters. And it's really cool.
Although CNCs are no longer as relevant as they used to be, with multiple entry points without routing through mod_rewriteit is difficult to implement links like /news/ofigennaya-novost-s-dlinnym-zagolovkom-v-url. And even if you pervert, it’s more pleasant to see the previous link in the URL than/news.php/ofigennaya-novost-s-dlinnym-zagolovkom-v-url

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question