Наличие единой точки входа на сайт. Плохой? Хорошо? Не проблема?

Question

Этот вопрос связан с просмотром выступления Расмуса Лердорфа из Drupalcon . Между прочим, этот вопрос и его разговор не имеют ничего общего с Друпалом ... это было просто дано на их доводе "против". Мой собственный вопрос также не имеет ничего общего с PHP. Это единственная точка входа в целом, что мне интересно.

В наши дни кажется, что большинство фреймворков предлагают единую точку входа для всего, что вы с ними строите. В своем выступлении Расмус упоминает, что считает это плохим. Мне кажется, он был бы прав в этом мышлении. Если все посетители сайта заходят через одну и ту же точку входа, разве все не застынет после того, как трафик достигнет определенной точки? Разве не было бы более эффективно разрешить людям прямой доступ к определенным точкам на сайте без того, чтобы их запрос проходил через ту же точку? Но, возможно, фактическое влияние не очень плохо? Может быть, современная архитектура справится с этим? Может быть, вы должны быть по-настоящему гигантскими в масштабе, прежде чем это даже стоит задуматься? Мне интересно, что люди на этом сайте думают об этой проблеме.

Answer 1

Короче говоря, Расм или интерпретация неверна.

Это показывает явное отсутствие понимания работы компьютеров. Чем больше что-то используется, тем более вероятно, что оно ближе к процессору, и, следовательно, быстрее . Имейте в виду, единственная точка входа! = Единственная точка отказа. Но это не относится к делу, когда люди говорят о единой точке входа, мы говорим о приложении, это единственная точка входа для вашей логики.

Не говоря уже о том, что с архитектурной точки зрения мозг не имеет центральной точки входа или не уменьшает количество точек входа в целом. Как только вы захотите сделать что-то одно в своем приложении на каждой точке входа, угадайте, сколько мест нужно изменить? Разобравшись с приложением, которое на каждой странице стояло само по себе, оно отняло необходимость изменить, и, уверяю вас, нам это нужно.

Answer 2

Как и все в разработке программного обеспечения, это зависит. Rasmus возражает против использования стилевого интерфейса фронт-контроллера - это снижение производительности, которое вы испытываете из-за необходимости загружать столько кода заранее при каждом запросе. Это на 100% верно. Даже если вы используете какой-либо модуль загрузки смарт-ресурсов / объект / и т.д., использование фреймворка является компромиссом в производительности. Вы получаете удар по производительности, но взамен вы возвращаетесь

1. Поощрение разделения "бизнес-логики" (что бы это ни было) и шаблонов / логики макета

2. Мгновенный и (что более важно) унифицированный доступ к объектам, которые вы будете использовать для запросов к базе данных, вызываемой службе, вашей модели данных и т. Д.

Для такого парня, как Расмус, это не стоит удачного выступления. Он программист C / C ++. Для него, если вы хотите отделить бизнес-логику высокопроизводительным способом, вы пишите расширение C / C ++ для PHP.

Так что, если у вас есть среда и команда, в которой вы можете легко писать расширения C / C ++ для PHP, и ваше соотношение времени и рынка к производительности приемлемо, тогда да, отбросьте вашу инфраструктуру фронт-контроллера.

Если это не ваша среда, подумайте об увеличении производительности, которое может принести среда фронт-контроллера вашему (вероятно) простому приложению CRUD .

Answer 3

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

Нет, одна точка входа сама по себе не является узким местом. Главная страница Google получает много просмотров, но у них много серверов.

Таким образом, ответ: это не имеет значения.

Answer 4

Я думаю, что это большое недоразумение - обсуждать это с точки зрения «один файл» против «несколько файлов».

Можно подумать, что поскольку точка входа находится в одном файле, то все, на чем мы должны сосредоточиться, - это код в этом одном файле - это неправильно.

У всех популярных фреймворков есть тонны файлов с кодом манипуляции ввода, кодом интерпретации и кодом проверки для запросов. Код не находится в одном месте, а распространяется в джунглях оператора require / include, вызывающего различные классы в зависимости от того, что запрашивается и как.

В обоих случаях запрос действительно обрабатывается разными файлами.

Почему тогда у меня должна быть одна точка входа с некоторой функцией _detect_uri (), которая должна вызывать несколько других функций, таких как strpos (), substr (), strncmp (), чтобы очистить, проверить и разделить запрос строка, когда я могу просто использовать несколько точек входа, удаляя этот код все вместе?

Взгляните на функцию CodeIgniters _detect_uri () в URI.php. Не выбирать на CodeIgniter, это всего лишь пример. Другие фреймворки делают то же самое.

Вы можете достичь целей шаблона MVC как с одной точкой входа, так и с несколькими точками входа.

Answer 5

Я думаю, что одним из самых больших преимуществ, которые вы имеете над наличием единственной точки входа, является безопасность. Все входные данные с меньшей вероятностью повредят систему, если она будет проверена и проверена в одном месте.

Answer 6

Просто добавим, что люди обычно думают о том, что, поскольку есть одна страница php, это одна страница, обслуживающая все запросы. Вроде как очередей.

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

Тем не менее, некоторые фреймворки могут содержать массу вещей, которые вам не нужны в сценарии ввода. Вроде как ловушка для удовлетворения всех возможных сценариев, и это может вызвать нагрузку.

Лично я предпочитаю несколько страниц, так же, как я смешиваю oop и процедурные. Мне нравится php по-старому.

Answer 7

Поскольку большинство фреймворков php mvc используют своего рода переписывание URL-адресов или, по крайней мере, синтаксический анализ чего-либо после index.php, единственная точка входа необходима .

Кроме того, я хотел бы предоставить точки входа для контекста, скажем, web (/ soap) / console /...

Answer 8

Это то, что я сначала подумал, но это не похоже на результат. В конце концов, ваша точка входа (обычно) выполняет только несколько вещей: установка некоторых констант среды, включая загрузчик начальной загрузки, опциональный перехват любых исключений и диспетчеризация фронт-контроллера. Я думаю причина, по которой это не является неэффективным, заключается в том, что этот файл не изменяется в зависимости от контроллера, действия или даже пользователя.

Я чувствую, что это странно. Я сам сейчас создаю небольшую инфраструктуру MVC, но она немного противоположна большинству платформ, которые я использовал. Я поместил логику контроллера в доступ к файлу. Например, index.php будет содержать IndexController и его действия. Этот подход хорошо работает для меня, по крайней мере.

Answer 9

Определенно есть недостатки в использовании файловой архитектуры фронт-контроллера. Как объясняет Saem, доступ к одному и тому же файлу в целом выгоден для производительности, но, как объясняют Алан Сторм и Расмус Лердорф, пытаясь заставить код обрабатывать многочисленные ситуации (например, фронт-контроллер пытается обработать запрос для каждой «страницы» сайта). ) приводит к раздутой и сложной коллекции кода. Использование раздутой и сложной коллекции кода для каждой загрузки страницы может считаться плохой практикой.

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

Наличие структуры каталогов, которая фактически используется веб-сервером, может упростить веб-сервер и сделать его более очевидным для разработчиков. Веб-серверу проще обслуживать файлы путем перевода URL-адреса в расположение, которое они обычно представляют, чем переписывать их в новый URL-адрес. Файловая архитектура без фронт-контроллера может быть более очевидной для разработчика, потому что вместо того, чтобы начинать с раздутого контроллера, чтобы обрабатывать все, они начинают с файла / контроллера, который более специфичен для того, что им нужно разрабатывать.