Я вижу, что во многих реализациях MVC для веб-сайтов есть точка с одним входом, такая как файл index.php, а затем анализирует URL-адрес, чтобы определить, какой контроллер запускать. Это кажется довольно странным для меня, потому что это связано с необходимостью переписывать URL-адрес с помощью перезаписываемых Apache и с достаточным количеством страниц, из-за которых один файл будет раздуваться.
Почему вместо этого вместо того, чтобы отдельные страницы были контроллерами? Я имею в виду, если у вас есть страница на вашем сайте, в которой перечислены все зарегистрированные участники, то пользователи members.php страниц будут переходить к контроллеру для членов. Этот php-файл будет запрашивать модель участников для списка членов из базы данных и передавать ее в представление членов.
Мне может быть что-то не хватает, потому что я только недавно обнаружил MVC, но эта одна проблема прослушивала меня. Разве такой дизайн не был бы предпочтительнее, потому что вместо того, чтобы иметь один раздутый входной файл, который все страницы неинтуитивно называют моделями и представлениями для конкретной страницы, содержится, инкапсулируется и вызывается со своей соответствующей страницы?
По моему опыту, наличие однократной точки имеет несколько пресловутых преимуществ:
Он облегчает централизованные задачи, такие как загрузка ресурсов (подключение к db или серверу memcache, протоколирование времени выполнения, обработка сеанса и т. Д.). Если вы хотите добавить или удалить централизованную задачу, вам просто нужно изменить один файл, который является index.php.
Анализ URL-адреса в PHP делает «виртуальный URL» отделенным от физического макета файла на вашем веб-сервере. Это означает, что вы можете легко изменить свою систему URL (например, для целей SEO или для интернационализации сайта) без фактического изменения местоположения ваших скриптов на сервере.
Однако иногда наличие точки входа может быть пустой тратой ресурсов сервера. Это явно относится к статическому контенту, но также когда у вас есть набор запросов, которые имеют очень специфическую цель, и вам просто нужен очень маленький набор ваших резорбций (возможно, им не нужен доступ к БД, например). Тогда вы должны рассмотреть возможность иметь более одной точки входа. Я сделал это для сайта, над которым я работаю. Он имеет точку входа для всего «стандартного» динамического содержимого, а другой для вызовов общедоступного API, который требует гораздо меньше ресурсов и имеет совершенно другую систему URL.
И последнее замечание: если сайт хорошо реализован, ваш index.php не обязательно обязательно раздувается 🙂
это все о том, чтобы быть СУХОЙ, если у вас много запросов на обработку php-файлов, у вас будет дублированный код. Это просто делает для кошмара обслуживания.
Посмотрите на «главную» страницу индекса для CakePHP, https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php
независимо от того, насколько большой размер приложения, мне никогда не нужно было это изменять. так как он может раздуться?
При деактивации непосредственно в контроллерах при использовании структуры MVC он исключает возможность внедрения плагинов или фильтров контроллера в зависимости от используемой структуры. Наличие единой точки входа стандартизирует загрузку приложения и модулей и выполнение ранее упомянутых плагинов перед доступом к контроллеру.
Также Zend Framework использует собственную переработку URL в виде маршрутизации. В приложениях, которые используют Zend Framework, я работаю над файлом .htaccess, возможно, 6 строк переписывающих и условий.
Единственная точка входа, безусловно, имеет свои преимущества, но вы можете получить почти такую же выгоду из центрального файла, который находится в верхней части каждой отдельной страницы, которая обрабатывает подключения к базе данных, сеансы и т. Д. Она не раздута, она соответствует принципам СУХОЙ (кроме для этого требуется строка), он разделяет логику и презентацию, и если вы измените расположение файлов, простой поиск и замена исправит его.
Я использовал и то и другое, и я не могу сказать, что один из них значительно лучше или хуже для моих целей.