"Точки входа"

 
0
 
PHP
ava
odminchek | 22.03.2013, 02:46
Здравствуйте, товарищи. Вопрос у меня немножко ламерский, но просто не приходилось доселе сталкиваться с подобной проблемой.

Подход 1: заюзать файлы (например) index.php, login.php, register.php и т.д., прикрутить .htaccess, сделать всё на файлах, ИЛИ:
Подход 2: одна точка входа, т.е. index.php, в кторой будет нечто вроде:

if ($_GET['page'] == 'login') require_once('login.php');
elseif (...) и т.д.


Какой подход наиболее оптимален, какие есть плюсы и минусы (в производительности/удобстве разработки и т.д.)? Большая просьба отвечать развёрнуто, т.к. передо мной сейчас стоит этот вопрос, и его нужно во что бы то ни стало решить. Заранее спасибо.
Kommentare (14)
ava
Fortop | 22.03.2013, 02:01 #
Единая точка входа упрощает контроль за приложением (инициализация, подключение БД, права доступа и т.д.)
За это ты расплачиваешься некоторой долей производительности.
ava
Арантир | 22.03.2013, 02:31 #
doctor2k, ну второй подход у вас тоже не очень =)
У вас между первым и вторым, в принципе, разницы не так уж много. Добавляя некий общий скрипт в начало каждого файла, типа login.php, вы получили бы тот же эффект.

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

Такой метод активно используют веб-фреймворки. Почитайте документацию любого MVC-фреймворка, в частности, раздел об создании bootsrtap-файла (он же index.php). Это должно помочь вам понять когда  и чем единая точка полезна.
ava
odminchek | 22.03.2013, 02:41 #
У меня почему-то имеется убеждение, что есть решать проблему "в лоб", то с точки зрения производительности результат будет наилучшим. ООП? Да, круто. MVC? Замечательно. Наш путь - писать на процедурах винигрет, но в строгом соответствии с ТЗ - и тогда у нас всё будет круто, поскольку расширять не придётся. К счастью, убеждение остаётся всего-лишь убеждением, никак не влияющим на реальный подход к разработке, однако хотелось бы узнать, в чём конкретно моё убеждение ошибочно. Вернее, я предполагаю, что оно ошибочно.
ava
Арантир | 22.03.2013, 04:22 #
Цитата (doctor2k @  22.3.2013,  01:41 findReferencedText)
 что есть решать проблему "в лоб", то с точки зрения производительности результат будет наилучшим

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

Цитата (doctor2k @  22.3.2013,  01:41 findReferencedText)
расширять не придётся

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


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

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

Одна точка входа упростит вам разработку. В частности то, что выполняется для каждого запроса 
Цитата (Fortop @  22.3.2013,  01:01 findReferencedText)
инициализация, подключение БД, права доступа и т.д.

ava
Gold Dragon | 22.03.2013, 06:29 #
Цитата (doctor2k @  22.3.2013,  02:46 findReferencedText)
Подход 2: настроить .htaccess так, чтобы он всегда указывал на index.php, а в index.php написать нечто вроде:
Зачем такой изврат... Можно и проще..
Создаёшь в index.php в самом начале константу типа так

// Установка флага родительского файла
define('_JLINDEX', 1);


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

// запрет прямого доступа
defined('_JLINDEX') or die();

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

Единая точка это в первую очередь безопасность. Во-вторых,  конечно "упрощает контроль за приложением (инициализация, подключение БД, права доступа и т.д.)"
ava
Sanchezzz | 22.03.2013, 08:55 #
ТС Нужно определится изначально какие параметры вам нужны через modrewrite

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



# http://site/ru/code/ (sample argument) / (sample argument) / title or ID
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2&$3=$4&$5=$6 [NC,L]
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2&$3=$4&$5=$6 [NC,L]

# http://site/ru/code/ (sample argument) / title or ID
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2&$3=$4 [NC,L]
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2&$3=$4 [NC,L]

# http://site/ru/code
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2 [NC,L]
RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2 [NC,L]


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

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


ava
bars80080 | 22.03.2013, 10:59 #
Цитата (Sanchezzz @  22.3.2013,  08:55 findReferencedText)
Года два назад уже когда я писал crealog использовал вот такой подход к URL

Который 90% удовлетворяет потребности.



код PHP

http://site/ru/code/ (sample argument) / (sample argument) / title or ID

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2&$3=$4&$5=$6 [NC,L]

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2&$3=$4&$5=$6 [NC,L]

http://site/ru/code/ (sample argument) / title or ID

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2&$3=$4 [NC,L]

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2&$3=$4 [NC,L]

http://site/ru/code

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)$ index.php?lang=$1&code=$2 [NC,L]

RewriteRule ^([a-zA-Z_0-9]+)/([a-zA-Z_0-9\-]+)/$ index.php?lang=$1&code=$2 [NC,L]



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



Получается при заходе на страницу /ru/login 

В Index.php вы получите следующий GET Массив параметров 

$lang = Язык

$code = login 


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

RewriteRule ^(.*)$ index.php [L,QSA]
и хватит. а там уже на пхп как угодно его распарсишь из $_SERVER, причём правила тогда могут быть как угодно разнообразны и даже динамичны.
ava
odminchek | 22.03.2013, 12:44 #
Цитата (bars80080 @  22.3.2013,  10:59 findReferencedText)
никогда не понимал принципиальной необходимости дербанить урл всенепременнейше в .htaccess, если всё всё равно сваливается в index.php

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

Цитата (Gold Dragon @  22.3.2013,  06:29 findReferencedText)
Создаёшь в index.php в самом начале константу типа так

код PHP

1:

2:

// Установка флага родительского файла

define('_JLINDEX', 1);





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

код PHP

1:

2:

// запрет прямого доступа

defined('_JLINDEX') or die();



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

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


Цитата (Gold Dragon @  22.3.2013,  06:29 findReferencedText)
Единая точка это в первую очередь безопасность.

Верно, не ведь это не единственный способ обеспечения безопасности.
ava
Sanchezzz | 22.03.2013, 15:05 #
Скажу в свое оправдание это было очень давно и я был юн=)

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


location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php; } }

ava
Fortop | 22.03.2013, 21:31 #
Цитата (doctor2k @  22.3.2013,  02:41 findReferencedText)
Наш путь - писать на процедурах винигрет, но в строгом соответствии с ТЗ - и тогда у нас всё будет круто, поскольку расширять не придётся.

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

Но уже примерно на 250-300к строк кода такой подход нереентерабелен и нерентабелен.
ava
Арантир | 22.03.2013, 22:20 #
Цитата (doctor2k @  22.3.2013,  11:44 findReferencedText)
Мне кажется, неправильных вариантов здесь нет.

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

Цитата (bars80080 @  22.3.2013,  09:59 findReferencedText)
очень многие пишут:
Цитата (Arantir @  22.3.2013,  01:31 \\"findReferencedText\\")
Добавляя некий общий скрипт в начало каждого файла, типа login.php
Должен заметить. что я все же склоняюсь к
Цитата (Arantir @  22.3.2013,  01:31 findReferencedText)
сайт работает как целостное приложение

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

Разве что это сайт-визитка на 3 страницы... Но пример ТС со ссылкой на логин (вход) уже намекает на права доступа (как минимум разделение гость-пользователь), что намного удобнее, когда пользователь — структурная часть приложения (сайта), а не куча проверок перед каждой второй операцией.
И идея целостного приложения еще не означает потребность написания какого-то большого backend-фреймворка. Разве что автолодер классов там добавится, а все остальное — это объектное представление все тех же функций, которые и так будут в варианте с отдельными скриптами.
ava
odminchek | 23.03.2013, 00:48 #
А если сам по себе сайт прост, и в чём-то даже примитивен, но при этом народ на него ходит - порядка 10к посетителей ежедневно, то как одна точка входа скажется на производительности? А на количестве серверов? А при 20к в сутки? А при 50к? smile чисто теоретически. Ну вот в качестве примера можно взять например тот-же http://govnokod.ru/ - довольно простой движок, но народ ходит. Вот там как может быть сделано? Каковы показатели производительности при этом?
ava
Арантир | 23.03.2013, 01:52 #
А вы думаете, что в наше-то время PHP код выполняется каждый раз для каждого запроса? Это же прошлый век...

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


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

Примерно так же и с PHP, только немного специфично. Исходный код приложения представляет собой удобную для разработчика архитектуру, но результаты ее выполнения кешируются (с обеспечением их актуальности) и отдаются пользователю минуя излишние (зря повторяемые) операции. При этом значимость самой структуры приложения значительно уменьшается.
ava
odminchek | 23.03.2013, 21:11 #
Яснопонятно)
Registrieren Sie sich oder melden Sie sich an, um schreiben zu können.
Unternehmen des Tages
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
advanced
Absenden