Structurer un grand projet PHP

Question

PHP est un langage largement flexible, je pourrais le faire de toute façon et n'importe où. Cependant, quelles seraient selon vous les meilleures pratiques pour structurer de grands projets?

J'ai construit un CMS sur mesure pour un client, mais comme il a été ma première incursion dans un grand projet est un peu un gâchis. Il y a des fichiers partout, avec une structure de dossier très mauvaise. Un ami a suggéré que les seuls fichiers qui devraient se trouver dans le répertoire racine du site sont les fichiers "page" - c'est-à-dire les fichiers qui contiennent du HTML et que vous devriez avoir des dossiers séparés pour chacun des différents éléments , qui peut ensuite être facilement tiré dans différentes pages avec inclus. Est-ce que tout le monde recommande cette route ou est-elle entièrement régie par des préférences personnelles?

Answer 1

Si le démarrage d'un nouveau projet, envisagez d'utiliser un cadre, ou jeter un oeil à la façon dont ils le font.

En général, les structures dictent ou suggèrent une structure de répertoire.

Même si vous ne finissent pas à l'aide d'un: La façon dont ils structurent leurs projets provient généralement de tonnes et des tonnes d'expérience.

Personnellement, je aime la façon dont Zend Framework de structuration, et son autochargeur, le meilleur. Mais il existe plusieurs options et philosophies.

questions Cadre:

• What PHP Framework to choose

• Best PHP framework for an experienced PHP developer?

• More Framework questions....

En général liées:

• In a PHP project, how do you organize and access your helper objects?

• How to use PHP for large projects?

Answer 2

Je recommande d'avoir un seul fichier dans le dossier racine, étant index.php, et faire de ce fichier comprennent tout ce qui est nécessaire aux demandes reçues. Si vous faites de la POO, il est généralement pratique de placer vos classes dans une structure de dossiers qui imite votre espace de noms (simulé en PHP < 5.3 ou réel en 5.3+). Cela permet un chargement automatique facile des classes.

Answer 3

Personnellement, j'utiliser la façon dont vous avez décrit dans le dernier paragraphe, et trouvent utile, propre & rapide à execure. Assurez-vous de déplacer tous les éléments courants dans les bibliothèques/fichiers courants, en aucun cas vous devriez copier/coller.

Une autre (commune) manière de structurer est lorsque vous utilisez des cadres, qui mettent en application habituellement une structure de projet spécifique.

Answer 4

Je dirais que cela n'a pas d'importance trop comment vous mettez en forme votre application dans le dossier. Avoir des fichiers est une nécessité et cela a un impact sur l'application. Aborder cet impact. Ce n'est pas comme ça que vous mettez en forme vos dossiers, c'est pourquoi.Trouver quelques idées ci-dessous. Pour des raisons de sécurité, vous ne devez placer que les scripts dans la racine Web qui sont censés être directement utilisables par le monde entier. En outre, si vous avez créé des fichiers pendant l'exécution, assurez-vous qu'ils ne sont pas écrasés lorsque vous déployez/mettez à jour votre application sur votre serveur. Que ce soit dans votre routine de déploiement ou dans la disposition des dossiers, c'est à vous de décider. Pour des raisons de performances, tenez compte du fait que l'inclusion de fichiers/codes qui ne sont pas nécessaires pour une requête particulière ralentira votre application sans nécessité. De même, avoir beaucoup de include_paths à rechercher. Assurez-vous que PHP peut trouver les fichiers dont il a besoin rapidement.

Pour la maintenabilité, utilisez le bon sens. Il n'y a pas de règle que vous devez avoir un fichier par classe. Il n'y a également aucune règle que vous devez suivre la disposition de dossier de PEAR. PEAR est une convention répandue et raisonnable, mais jetez vos fichiers dans un seul dossier si cela a du sens pour cette application particulière.

IMO, une application n'est pas les fichiers, c'est le code à l'intérieur. Il est beaucoup plus important d'avoir votre code bien organisé que vos fichiers. Avoir une disposition de fichier désordonnée est beaucoup moins un problème que d'avoir une architecture désordonnée.