PHP Bootstrapping meilleure méthode?

Question

Est-il recommandé d’amorcer votre application PHP? J'ai trouvé deux façons d'amorcer mon application PHP. Besoin de suggestions qui sont une meilleure façon.

Premier.
Définir une constante pour les structures de dossiers

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

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

Deuxième
Utilisation de ini_set, définissez le chemin d’inclusion vers la racine de l’application

$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';

Dites-moi quel est le meilleur moyen.

Dans le cas d'une application à forte charge, quelle serait la meilleure méthode ??

Answer 1

Utilisez ini_set pour le définir dans le répertoire ci-dessus de votre application. C'est pourquoi vous pouvez utiliser les chaînes littérales dans vos instructions require. De plus, cela facilite l’utilisation du code de réutilisation

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

Cela ressemble à l'idée en Java d'avoir des importations pleinement qualifiées de com.whatever.app.more, ou comment, en python, toutes les importations d'applications doivent être absolues par rapport à cette application.

Objet: Application à forte charge

Sauf si vous chargez plusieurs milliers de fichiers, le temps qu’il faut pour inclure des fichiers n’est probablement pas un goulot d’étranglement. Mais si c'était le cas, vous avez deux options. L'un d'entre eux est APC, qui met en mémoire cache les résultats de include. Une autre solution consiste à tout charger depuis un seul fichier, de la même manière que la concaténation des fichiers javascript en un seul fichier pour améliorer les performances (par hasard, APC dispose d’une fonction qui vous donne ces informations). APC est vraiment facile à installer et totalement transparent, pour un boost de ~ 50% de performances supérieures .

Answer 2

Mieux vaut utiliser des chemins absolus que de laisser PHP trouver le fichier dans l'un des chemins d'inclusion indiqués.

J'ai donc tendance à utiliser le premier moyen avec une constante contenant le chemin absolu vers la racine de l'application.

Answer 3

C'est ce que je fais:

• Placez un répertoire / include en haut de la racine du document (ou le nom de votre choix) pour toutes les classes, fonctions d'assistance, etc.;
• Faites en sorte que le répertoire / include ne soit pas servi en utilisant mod_rewrite;
• Vous y trouverez un fichier appelé, par exemple, setup.php, qui configure les paramètres ini, les chemins d'accès, etc. pertinents;
• Ce fichier est inclus dans chaque page par chemin relatif; et
• Tout le reste peut alors compter sur les paramètres qu'il a créés.

Exemple de règles de réécriture pour .htaccess de niveau supérieur:

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

Je suis peut-être légèrement en retrait. Je n'ai pas mes règles standard à portée de main. Vous remarquerez que je crée une erreur 404 plutôt que 403 (interdit). C'est délibéré. Lorsque vous vous connectez à un système, il ne dit pas & Quot; utilisateur inconnu & Quot; ou " mot de passe incorrect " parce que cela vous dit quelque chose. Je préférerais prétendre qu'il n'y avait pas du tout de répertoire / include plutôt que de dire qu'il est là mais vous ne pouvez pas le regarder.

À ce stade, vous pouvez configurer tout ce dont vous avez besoin pour que le reste de votre code puisse simplement faire:

require 'Class.php';

ou même définir un __autoload() pour que cela se produise automatiquement.

Answer 4

Voici un exemple de mon chargeur d'amorçage:

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');

J'irais personnellement avec la deuxième voie. J'ai appris à aimer l'include_path: la recherche dans de nombreux répertoires a probablement eu un impact négatif sur les performances, mais je doute que ce soit significatif. Cela empêche également les erreurs d’oublier d’inclure la constante de chemin.

En passant, j’ai mis mes contrôleurs, etc. dans /application/ et des bibliothèques dans /library/. Tout cela va au-dessus de la racine Web. Cela empêche complètement les utilisateurs d'accéder à ces fichiers, ce que vous devez sinon prendre des précautions si vous avez tout sous la racine du document. Si votre hôte le prend en charge (certains hôtes partagés ne le font pas), profitez-en!

Mettre à jour

  

Dans le cas d'une application à forte charge, est-il préférable d'utiliser la deuxième méthode ??

À mon avis, si vous deviez surveiller ce qui se trouve dans votre include_path (par exemple, sur ma machine de développement Windows, j'ai toutes sortes de choses dont je n'ai pas besoin: SQL Server, Ruby, etc.) et devait éliminer tout ce qui n’était pas nécessaire, la deuxième méthode serait satisfaisante.

Une autre chose que vous pouvez faire est de vider require à la fin du script et de le coder dans votre fichier php.ini.

Vraiment, cependant. Je ne pense pas que cela va être un goulot d'étranglement dans les performances de votre système. Utilisez ce qui est plus facile pour vous.

Avez-vous des problèmes de performances sur un site que vous utilisez ou s'agit-il de précautions? Je peux voir pourquoi vous voudriez préoptimiser (je dois m'empêcher de le faire) mais sérieusement. Traitez ces problèmes quand ils se présentent. Lorsque vous êtes dans la position chanceuse de disposer d'un site populaire, vous pouvez vous en occuper. En fin de journée, ce n’est pas un cauchemar si vous devez remplacer quelques <=> s.

.

Answer 5

Je préfère de loin la deuxième méthode - je l’utilise sur un grand projet PHP et l’apprécie beaucoup.