PHP Bootstrapping лучший метод? - PullRequest
Новая
       28

PHP Bootstrapping лучший метод?

3 голосов
/ 01 февраля 2009

Это хорошая практика для загрузки вашего PHP-приложения. Я нашел два способа начальной загрузки моего PHP-приложения. Нужны предложения, которые лучше.

Первый.
Определить константу для структуры папок 

$controllerPath = 'controller';
define('CONTROLLER', str_replace('\\', '/', realpath($controllerPath)).'/');

//usage
require_once CONTROLLER . 'somecontroller.php';

Второй
Используя ini_set, установите путь включения к корню приложения 

$rootPath = $_SERVER['DOCUMENT_ROOT'];
$includePath = ini_get('include_path');
ini_set('include_path', '.'.PATH_SEPARATOR.$rootPath.PATH_SEPARATOR.$includePath);

//usage
require_once 'controller/somecontroller.php';

Пожалуйста, скажите мне, какой способ лучше.

В случае применения с высокой нагрузкой, который будет лучшим методом ??

Ответы [ 5 ]

4 голосов
/ 01 февраля 2009

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

require 'coolapp/class/Model.php'
require 'coolapp/display/Router.php'
require 'spinoff/display/JsView.php'
// etc

Это похоже на идею в java иметь полностью квалифицированный импорт com.whatever.app.more, или как в python все импорты приложений должны быть абсолютными по отношению к этому приложению.

Re: Приложение высокой нагрузки

Если вы не загружаете много тысяч файлов, время, необходимое для включения файлов, вероятно, не является проблемой. Но, если бы это было так, у вас есть пара вариантов. Одним из них является APC, который кэширует результаты include в памяти. Другой способ - загрузить все из одного файла, аналогично тому, как файлы javascript объединяются в один для повышения производительности (по совпадению, в APC есть функция, которая предоставляет вам эту информацию). APC действительно прост в настройке и полностью прозрачен, для повышения производительности ~ 50% .

3 голосов
/ 01 февраля 2009

Лучше использовать абсолютные пути, чем позволить PHP найти файл по одному из указанных путей включения.

Итак, я склоняюсь к первому способу, используя константу, которая содержит абсолютный путь к корню приложения.

1 голос
/ 02 февраля 2009

Вот пример моего загрузчика: 

if (!defined('APPLICATION_PATH')) {
    define('APPLICATION_PATH', realpath(getcwd() . '/../application'));
}

/**
 * Add the APPLICATION_PATH and the library dir to the include_path
 */
set_include_path(get_include_path() . PATH_SEPARATOR . APPLICATION_PATH . PATH_SEPARATOR . realpath(APPLICATION_PATH . '/../library'));

/**
 * Load the file loader to setup the class autoloader
 */
include_once 'Loader.php';
if (!class_exists('Loader')) {
    die('Could not load class loader.');
}

spl_autoload_register('Loader::autoload');

Я бы лично пошел вторым путем. Я научился любить include_path: вероятно, наблюдается некоторое снижение производительности при просмотре большого количества каталогов, но я сомневаюсь, что это будет значительным. Это также предотвращает забывание ошибок о включении константы пути.

В дополнение к этому я поставил свои контроллеры и т. Д. В /application/, а некоторые библиотеки в /library/. Это все идет над корнем сети. Он полностью запрещает пользователям доступ к этим файлам, в отношении которых вы должны принять иные меры предосторожности, если у вас есть все под корнем документа. Если ваш хост поддерживает это (некоторые общие хосты этого не делают), воспользуйтесь этим!

Обновление

В случае приложения с высокой нагрузкой хорошо ли использовать второй метод ??

По-моему, если бы вы следили за тем, что у вас есть include_path (например, на моей машине с Windows dev у меня есть все, что мне не нужно: SQL Server, Ruby и т. Д.) И если бы вычеркнуть все, что не нужно, то второй способ будет в порядке.

Еще одна вещь, которую вы могли бы сделать, - сбросить include_path в конце скрипта и жестко закодировать его в файл php.ini.

Правда, правда. Я не думаю, что это будет узким местом в производительности вашей системы. Используйте то, что вам легче.

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

1 голос
/ 02 февраля 2009

Вот что я делаю:

  • Поместите каталог / include в верхней части корня вашего документа (или как вы хотите его называть) для всех классов, вспомогательных функций и т. Д .;
  • Сделайте так, чтобы каталог / include не обслуживался с помощью mod_rewrite;
  • Имейте там файл, скажем, setup.php, который устанавливает соответствующие ini-параметры, пути и т. Д .;
  • Этот файл включен в каждую страницу по относительному пути; и
  • Все остальное может полагаться на созданные им настройки.

Пример правил переписывания для верхнего уровня .htaccess: 

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /include/
RewriteRule ^include/ - [R=404,L]

Я мог бы быть немного выключен. У меня нет своих стандартных правил под рукой. Вы заметите, что я создаю ошибку 404, а не 403 (Запрещено). Это умышленно. Когда вы входите в систему, она не говорит «неизвестный пользователь» или «неверный пароль», потому что это вам что-то говорит. Я предпочел бы притвориться, что каталога / include вообще не было, а не сказать, что он там есть, но вы просто не можете его посмотреть.

В этот момент вы можете настроить все, что вам нужно, так что остальная часть вашего кода может просто сделать: 

require 'Class.php';

или даже определить __autoload(), чтобы это происходило автоматически.

0 голосов
/ 02 февраля 2009

Я предпочитаю второй способ - использовал его в большом PHP-проекте и получал огромное удовольствие.

...