Structure du projet pour PHP
Je suis nouveau sur PHP et je veux connaître la structure du répertoire pour les projets php. J'ai de l'expérience dans Java et dans Java nous avons src contient Java fichiers source, WEB-INF contient lib et jsp pages. Avons-nous une structure de répertoire standard similaire en PHP? Avons-nous également des couches en php comme nous avons des couches dans Java (par exemple Web, Service, DAO)
J'ai parcouru quelques liens. Mais chacun donne des réponses différentes.
Je ne sais pas si nous pouvons comparer les deux langues. Je veux juste m'en tenir à certaines normes.
Merci d'avance.
Nan. PHP est ce que vous en faites. Il peut s'agir de fichiers plats très simples, ou comme vous le souhaitez.
Cela étant dit, il existe quelques normes de codage convenues, mais il n'y a aucune "application" de ces normes. Ils sont appelés PSR (PHP Standards Recommendation). Il y a un fond à ce sujet ici: http://net.tutsplus.com/tutorials/php/psr-huh/
Vous pouvez consulter les normes une par une ici: http://www.php-fig.org/psr/
La plupart des cadres principaux suivent ces normes, et si vous allez en utiliser un, il peut être plus facile de suivre le flux.
Encore une fois, chaque framework, projet, plugin, programme, etc., a des dispositions différentes avec des structures de projet différentes. Une structure commune ressemble à ceci:
-framework_dir
-public_html
-js
-img
-css
-index.php
-protected/private
-controllers
-models
-views
-etc
Ils utilisent ensuite le .htaccess fichier pour bloquer l'accès aux répertoires protégés. Encore une fois, ce n'est que la représentation commune que j'ai vue dans plusieurs cadres. Si vous faites un projet personnel, utilisez simplement quelque chose qui vous convient. Chaque framework va vous donner une bibliothèque différente ou un moyen d'accéder aux données. Il n'y a pas de "couches", mais là encore chaque framework a des objets qui gèrent différentes zones (email, base de données, cache, http, logs, etc.). Parce qu'il y en a des dizaines, il ne tient qu'à vous de trouver ce qui correspond à votre philosophie ou à votre projet. Regardez quelques-unes des vidéos de blog de 5 minutes, voyez ce qui vibre, puis essayez-le pendant quelques jours. Si vous ne l'aimez pas, passez à un autre.
Avec l'invention de Composer, les gens ont désormais une place centrale pour enregistrer leurs projets pour que le monde les consomme, et d'autres personnes peuvent maintenant regarder cette base de code et voir des similitudes.
Le résultat est le suivant: https://github.com/php-pds/skeleton
En bref:
If a package has a root-level directory for ...
... then it MUST be named:
command-line executables bin/
configuration files config/
documentation files docs/
web server files public/
other resource files resources/
PHP source code src/
test code tests/
Cette norme ne fait aucune recommandation supplémentaire sur les répertoires qui doivent exister sous src ou public. Je suggérerais simplement d'avoir un espace de noms en dessous de src, et d'implémenter toute diversification de "modèles", "contrôleurs" etc. en le faisant via le nom de classe complet, par ex. s'il est décidé d'avoir un Projectname\Controller\WhateverController classe, il résiderait dans le chemin compatible PSR-4 src/Controller/WhateverController.php et être chargé automatiquement via Composer avec "autoload":{"psr-4":{"Projectname\\": "src"}}.
J'ai tendance à utiliser une structure de dossiers basée sur les fonctionnalités pour mes projets backend. Chaque dossier de fonctionnalités possède son propre contrôleur, gestionnaire et fichier de routes. Cela fonctionne bien pour api - backends. Cela ressemble à https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
Par exemple, nous avons une fonction Client avec un CustomerController, CustomerRepository, CustomerRoutes, ..
Ma structure de dossiers ressemble à ceci:
- build/
-- phpdox.xml
-- phpmd.xml
-- phpunit.dist.xml
- config/
- public/
-- .htaccess
-- index.php
-- assets/
- src/
-- Customer/
--- CustomerController.php
--- CustomerRepository.php
--- Customer.php
--- customer.routes.php
- tests/
- vendor/
composer.json
.gitignore
Malheureusement (ou pas?), Vous êtes très libre avec PHP. C'est à vous.
Voici ma structure:
framework/
controllers/
models/
configs/
files/
templates/
themes/
tmp/
index.php
init.php
.htaccess
Vous pouvez contrôler l'accès via .htaccess.
Pour une bibliothèque, j'utilise la structure suivante ... en plus j'ai inclus des recommandations que je n'utilise pas (encore)
PROJECT ROOT
|--composer.json
|--README.md
|--docs //for documentation files
|--tests //for Unit Tests
|--vendor //for external libraries (if everything isn't included through composer)
|--examples //examples of the library being used
|--config //any configuration files you may have
|--src //where the library's actual code "lives"
|--php //php source code, classes, any other scripts
|--View //html views, but actually php files that output html
|--Style //contains .css files
|--Script //contains .js files
|--Res //contains other deliverable resource files. Could be mp3 files, json etc
Actuellement, j'utilise uniquement composer.json, README.md et src parmi les fichiers racine. Mais je vais probablement utiliser les autres comme je l'ai décrit, quand j'arriverai à ce point.
En aucun cas, je pense que c'est "correct". Et cette configuration ne fonctionne que parce que j'ai un routeur php à chaque demande. Avec un .htaccess, vous pouvez acheminer un .css fichier vers /src/Style/requested_file.css.
Je voulais que la racine du projet soit nettoyée, et j'ai réussi. PHP Fig n'a pas PSR pour les structures de répertoires ... que je sache. J'avais espéré PSR-4, autoloader aurait eu des normes, mais ... pas vraiment, en ce qui concerne la structure du répertoire.
Vous pouvez regarder laravel , wordpress , PHP Mailer et autres bibliothèques php pour voir des exemples et voir ce que vous pourriez préférer