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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Однако в некоторых фреймворках может быть много всего, что вам не нужно делать в записи script. Похоже на то, чтобы удовлетворить все возможные сценарии, и это может вызвать нагрузку.

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

Ответ 9

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

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

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