Здравствуйте, товарищи. Вопрос у меня немножко ламерский, но просто не приходилось доселе сталкиваться с подобной проблемой.

Подход 1: настроить .htaccess так, чтобы конкретный URL (например, http://mydomain.local/login) обрабатывался конкретным файлом (например, login.php)
Подход 2: настроить .htaccess так, чтобы он всегда указывал на index.php, а в index.php написать нечто вроде:


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

P.S. Сейчас используется Подход 1, но почему-то иногда закрадываются сомнения в правильности такого выбора.

Это сообщение отредактировал(а) doctor2k - 22.3.2013, 01:52

Единая точка входа упрощает контроль за приложением (инициализация, подключение БД, права доступа и т.д.)
За это ты расплачиваешься некоторой долей производительности.

doctor2k, ну второй подход у вас тоже не очень =)
У вас между первым и вторым, в принципе, разницы не так уж много. Добавляя некий общий скрипт в начало каждого файла, типа login.php, вы получили бы тот же эффект.

Суть единственной точки входа в том, что сайт работает как целостное приложение, а не винегрет из скриптов. Отдельные страницы формируются путем вызова соответствующих методов и классов. Например, в концепции MVC роль "конструкторов страниц" выполняют контроллеры, которые определяют нужные для показа шаблоны и некоторые служебные действия.
Простыми словами — единая точка входа используется в основном тогда, когда по другому-то организовать приложение нельзя.

Такой метод активно используют веб-фреймворки. Почитайте документацию любого MVC-фреймворка, в частности, раздел об создании bootsrtap-файла (он же index.php). Это должно помочь вам понять когда  и чем единая точка полезна.

У меня почему-то имеется убеждение, что есть решать проблему "в лоб", то с точки зрения производительности результат будет наилучшим. ООП? Да, круто. MVC? Замечательно. Наш путь - писать на процедурах винигрет, но в строгом соответствии с ТЗ - и тогда у нас всё будет круто, поскольку расширять не придётся. К счастью, убеждение остаётся всего-лишь убеждением, никак не влияющим на реальный подход к разработке, однако хотелось бы узнать, в чём конкретно моё убеждение ошибочно. Вернее, я предполагаю, что оно ошибочно.

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


Ну это явно решает многие аспекты...


Если вcпомнить, что PHP и так задуман и создан не только как ориентированный на веб язык, но и как шаблонизатор, то PHP можно использовать "как есть" даже без ООП, паттернов и концепций вроде MVC.
Если это позволяет решить задачу в полной мере — то пожалуйста.

Всякие навороты в программировании не только для уменьшения производительности созданы =) Упрощение разработки снижает количество и вероятность ошибок. Следовательно, получаются более надежные решения задач, особенно при увеличении размера и масштабов решения (приложения, веб-сервисы, игровые сервера...).

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

Зачем такой изврат... Можно и проще.. 
Создаёшь в index.php в самом начале константу типа так


а во всех других файлах в самом начале просто проверяешь

ну или делаешь переадресацию..

Единая точка это в первую очередь безопасность. Во-вторых,  конечно "упрощает контроль за приложением (инициализация, подключение БД, права доступа и т.д.)"


Это сообщение отредактировал(а) Gold Dragon - 22.3.2013, 06:30

ТС Нужно определится изначально какие параметры вам нужны через modrewrite

Года два назад уже когда я писал crealog использовал вот такой подход к URL
Который 90% удовлетворяет потребности.


PS второй реврайт после каждого провела лишний если в первом сделать ?/ но тогда, когда это чудо юдо делалось не проканало.

Получается при заходе на страницу /ru/login 
В Index.php вы получите следующий GET Массив параметров 
$lang = Язык
$code = login 

никогда не понимал принципиальной необходимости дербанить урл всенепременнейше в .htaccess, если всё всё равно сваливается в index.php

и хватит. а там уже на пхп как угодно его распарсишь из $_SERVER, причём правила тогда могут быть как угодно разнообразны и даже динамичны.

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



мне же никогда это не было удобно. подключать кучу инициализирующих файлов, ломать голову с определением путей к ним (даже к одному уже заморочка). зачем? прописал в БД на урл /module/gaz/rembo/ запускать в последовательности скрипт /webout/modules/auto/sc1.php и ты знаешь, что у тебя уже необходимый набор подключений организован и существуют необходимый набор переменных с нужными значениями.
совсем не сложно при этом сделать переменный набор подключаемых опций

Лично для меня такой подход даёт: 1) наглядность, 2) определённость, 3) простоту редактирования. Но это мой выбор, сделанный для себя  если кому-то нравится по-другому - пожалуйста. Мне кажется, неправильных вариантов здесь нет.


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



Верно, не ведь это не единственный способ обеспечения безопасности.

Скажу в свое оправдание это было очень давно и я был юн=)

Сейчас я использую такой же метод как и сказал bars80080, потому что также убедился что лучше распарсить и в коде это обыграть.
Тока я не использую апач иза принципа, много крови попортил

до 25-50к строк кода и когда один-два разработчика - можете так писать.

Но уже примерно на 250-300к строк кода такой подход нереентерабелен и нерентабелен.

В программировании вообще неправильных вариантов нет, но есть сайты типа http://govnokod.ru/ ... 

Должен заметить. что я все же склоняюсь к 

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

Разве что это сайт-визитка на 3 страницы... Но пример ТС со ссылкой на логин (вход) уже намекает на права доступа (как минимум разделение гость-пользователь), что намного удобнее, когда пользователь — структурная часть приложения (сайта), а не куча проверок перед каждой второй операцией.
И идея целостного приложения еще не означает потребность написания какого-то большого backend-фреймворка. Разве что автолодер классов там добавится, а все остальное — это объектное представление все тех же функций, которые и так будут в варианте с отдельными скриптами.

А если сам по себе сайт прост, и в чём-то даже примитивен, но при этом народ на него ходит - порядка 10к посетителей ежедневно, то как одна точка входа скажется на производительности? А на количестве серверов? А при 20к в сутки? А при 50к?  чисто теоретически. Ну вот в качестве примера можно взять тот-же http://govnokod.ru/ - довольно простой движок, но народ ходит. Вот там как может быть сделано? Каковы показатели производительности при этом?

Это сообщение отредактировал(а) doctor2k - 23.3.2013, 01:31

А вы думаете, что в наше-то время PHP код выполняется каждый раз для каждого запроса? Это же прошлый век...

Для особо нагруженных проектов с динамическими страницами несложно кешировать такие страницы в виде предподготовленного шаблона (от <html> до </html>) с местами вставки данных. Для отдельного запроса формирование страницы будет таким же быстрым, как выполнение phtml-файла с php, включенным между текстом.
А статические страницы — так вообще отдавание файла сразу с кеша. На крайний случай — отдавание самим серверов (с учетом некого срока годности кеша), еще до php...
В целом, есть множество способов и методов для разных случаев.


Это можно сравнить с компилированием программы. Пишется программа на удобном высокоуровневом языке. Но она относительно долго компилируется, зато в скомпилированном виде довольно быстро работает. 

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

Это сообщение отредактировал(а) Arantir - 23.3.2013, 01:56

Яснопонятно)