Почему разработчики так безаппеляционно утверждают, что один фронт-контроллер лучше?

Question

[merlin-vrn]

Итак, цитата из документации. Они утверждают:

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

Аргументируя это тем, что-де каждый файл должен выполнять одни и те же действия для инициализации: подключать библиотеки и так далее:

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.

Через пол-страницы они предлагают использовать mod_rewrite для украшения урлов:

Using Apache's mod_rewrite (or equivalent with other web servers), the URLs can easily be cleaned up to be just /, /contact and /blog.

Итак, предлагается свернуть разные пути в один, а потом снова, уже на PHP, их различать и обрабатывать по-разному.



А ведь я мог сделать три файла /index.php, /contact/index.php и /blog/index.php и получить то же самое, зато по сравнению с подходом Symfony я:

• свалил бы всю маршрутизацию на веб-сервер — мне вообще не придётся делать её на PHP, дополнительно она стала бы быстрее
  
• не стал бы настраивать рерайтер, который неудобен в настройке, кроме того, тоже скорости не добавляет
  
• смог бы легко без лишних условных конструкций пропускать для отдельных точек входа необязательные шаги, например, анализ строки параметров запроса для статических страниц
  
• отдельные модули, представленные в данном случае в виде отдельных точек входа, оказались бы связаны слабее, что означает, что взаимное влияние меньше, проще адаптация, обновление и т. д.
  
  
  это то, что сообразил навскидку.
  
  
  
  То есть, я использую больше давно проверенного и более простого кода, а получаю в общем то же самое.
  
  
  
  При этом, гибкость не уменьшается. Нет никакой разницы, каким именно способом я настраиваю урлы: в магическом файлике добавляю магические строки, или же создаю директории и в них кладу магические файлики. Если мне нужно сменить урлы так, чтобы старые работали, никто не мешает мне для решения этой ненормальной задачи всё-таки задействовать рерайтер.
  
  
  
  По поводу «одинаковой иницизацизации» я тоже не согласен с аргументами: в этих ваших единых контроллерах всё равно приходится использовать магию типа «включение библиотек, анализ запроса, вывод ответа». Чем это отличается от строки «включить стандартную инициализацию» в отдельных точках входа?
  
  
  
  Я думаю, вопрос на самом деле касается не только Symfony — ведь все так делают — от Joomla до Dokuwiki. Объясните, чем это один фронт-контроллер настолько лучше, что используют его, несмотря на очевидные преимущества отдельных точек входа?

Answer 1

[Николай Васильчук]

С одной точкой входа можно не париться по поводу маршрутизации вообще. Вы добавляете новый маршрут в конфиг и заворачиваете его на нужный контроллер. Всё. При грамотной автозагрузке, вам не надо заморачиваться по поводу того, какие классы нужны для этого конкретного контроллера. Когда количество маршрутов приближается к сотне, начинаешь понимать, что так значительно проще.

Answer 2

[Назар Мокринский]

/blog выглядит более приятно, чем /blog/index.php и скрывает детали реализации + есть ещё динамический роутинг, когда вы заранее можете не знать, какой URL придет, и нужно сначала будет поискать в БД или ещё где-то.

Comments

[merlin-vrn]

/blog/ = /blog/index.php

Про динамический роутинг — можно конкретнее? Стоит ли это того настолько, чтобы изобретать велосипед, не используя возможности веб-сервера?

[Назар Мокринский]

А ещё это освобождает от дублирования кода, необязательные шаги и ненужные классы пропускаются автоматически, если грамотно реализована автозагрузка классов и всё правильно сконфигурировано.

[Назар Мокринский]

Например, у меня многоязычный сайт. Одна и та же страница новостей может выглядеть по разному для каждого языка:

/News/Cool_article
/Новости/Крутая_статья
/Новини/Крута_стаття

При этом файлов не существует, и вам не нужно предусматривать все варианты роутинга в .thaccess — просто посылаете всё в index.php, а он разберется что и к чему в зависимости от локали и прочих параметров, и при обновлении системы если изменятся какие-то внутренние правила работы это внешне ни на что не повлияет.

[merlin-vrn]

Повторяю, пропуск ненужных классов и ненужных шагов тут on par с перевесом отдельных точек входа: для фронт-контроллера нужно реализовывать грамотную автозагрузку и что-то правильно конфигурировать, а в случае отдельных точек входа уже всё готово.

Дублирование кода сводится к дублированию одной строки: include «standard_init.php»; — в подходе с фронт-контроллером всякой маршрутизационной магии намного больше. Хотя она не дублируется сама по себе, да, зато она дублирует структуру директорий на диске и код вебсервера. Велосипед с потерей эффективности, проще говоря.

[Назар Мокринский]

а в случае отдельных точек входа уже всё готово

А я думал, это в одном контроллере всё уже готово (в случае фреймворка скорее всего даже до вас), а в случае отдельных точек вы реализовываете одно и то же каждый раз.

[merlin-vrn]

Объясните, что именно я реализовываю каждый раз? include «standard.php»?

[Назар Мокринский]

А у вас кроме этой строки там больше ничего нет?
Если include «standard.php» встречается в десяти файлах — это уже признак того, что его нужно вынести на уровень выше как общую часть.
Разработчики перешли от разбросанных по всему проекту точкам к одной потому что её легче контролировать, легче изменять, можно изменять внутреннюю логику и прочее, не беспокоясь что файл /blog/index.php переменуется в /blog/post.php или ещё чего нибудь сломает все индексы поисковых систем. Любые изменения адресов, префиксов/суффиксов, редиректов, удобочитаемых URL и прочего настраиваются строчкой-двумя в конфигурационном файле или вообще через админ панель, не трогая настройки хоста. В вашем же случае любой рефакторинг архитектуры напрямую влияет на конечные страницы, что можно исправить только рерайтом страниц через настройки хоста, что весьма криво.

[merlin-vrn]

А то, что у меня сотня файлов начинается с чего-то вроде «use Symfony\Component\HttpFoundation\Request;» — чем-то лучше? Можно как-то от этого избавиться, судя по вашему комментарию — это уже признак того, что надо…

А сломать так же можно и, скажем, правила рерайтера. Контролировать отдельные точки входа ничуть не сложнее одной с невнятными маршрутами в виде комментариев со странной структурой.

[Назар Мокринский]

use Symfony\Component\HttpFoundation\Request;

Это уже особенности конкретного фреймворка, и не обязательная часть. Вы немного путаете вещи, пространства имен — это то, что как раз упрощает работу разносторонних компонентов, не позволяя им мешать друг другу. В большой системе вместо этого вам бы просто пришлось писать при каждом вызове класса вместо одной строчки в начале и Request по коду что-то вроде Symfony_Component_HttpFoundation_Request каждый раз. К тому же, при использовании класса, например, PhpStorm автоматически прописывает в начале файла указанную вами строчку.

Контролировать отдельные точки несравнимо сложнее потому что они отдельные, а простые правила роутинга можно при небольшом количестве увидеть все сразу на одной странице — и сразу понять, какой запрос куда пойдёт.

Если вам не нравится конкретно Symfony — попробуйте что-то другое, могу показать свой велосипед, там маршруты прописываются иначе, и предельно просто, примерно так

{
	"galleries"	: [
		"browse",
		"add",
		"edit",
		"delete"
	]
}

в каждом модуле. Система просматривает такие файлы, и определяет куда отправить запрос — всё просто и очевидно, а на уровне более высоком можно перехватить многоязычные запросы и отправить сюда же.

[merlin-vrn]

Прошу понять правильно, мне не «не нравится» симфони, мне непонятен подход.

Я понимаю разницу. Я имел ввиду, что вот конкретная реализация, здесь да, убрали одно, но вместо этого появилось нечто другое, оно в смысле дублирования, простоты и очевидности ничем не лучше (а то и хуже). Кстати, в докувики и джумле это явно лучше, чем в симфони — там в разного рода файлах и строка подключения библиотеки разная, так что она уже не просто магическая, а несёт некоторую семантику (определяет назначение данного файла в компоненте). И она одна, в отличие от десятка в некоторых файлах симфони.

И что же, в вашем фреймворке вообще нет подключения некоторой типовой универсальной библиотеки? Хорошо, а как вы так настраиваете «грамотную предзагрузку классов»?

[Назар Мокринский]

Универсальная библиотека — набор из десятка классов, и ещё кучки функций. Автозагрузка реализована так:

/**
 * Auto Loading of classes
 */
spl_autoload_register(function ($class) {
	if (substr($class, 0, 3) == 'cs\\') {
		$class	= substr($class, 3);
	}
	$class	= explode('\\', $class);
	$class	= [
		'namespace'	=> count($class) > 1 ? implode('/', array_slice($class, 0, -1)) : '',
		'name'		=> array_pop($class)
	];
	_require_once(CLASSES."/$class[namespace]/$class[name].php", false) ||
	_require_once(TRAITS."/$class[namespace]/$class[name].php", false) ||
	_require_once(ENGINES."/$class[namespace]/$class[name].php", false) ||
	(
		mb_strpos($class['namespace'], "modules/") === 0 && _require_once(MODULES."/../$class[namespace]/$class[name].php", false)
	) ||
	(
		mb_strpos($class['namespace'], "plugins/") === 0 && _require_once(PLUGINS."/../$class[namespace]/$class[name].php", false)
	);
});

Грузятся только используемые классы, и только тогда, когда они используются.
Но кроме того, чтобы просто подключать классы, тут ещё реализована возможность переопределять системные классы своими, положив в пространство имен custom, поэтому код немного пере усложнён. Так же подключается загрузчик composer, который работает аналогично.