Avis sur architecture

Bonjour à tous,
Je développe depuis pas mal de temps en PHP, et j'utilise plus ou moins la même structure.

Seulement, après des lectures fort intéressantes, j'ai commencé à songer à une nouvelle arborescence, que je vous présente ci-dessous (nom de projet/ Dummy).


Dummy

config

config.php

inc

Autoload.inc.php (configuration de l'autoload)

functions.inc.php (toutes les fonctions utilitaires de l'appli)

constants.inc.php (toutes les constantes)

controllers (éventuellement d'autres contrôleurs)

main

src

web (toutes les classes liées à l'interface utilisateur)

services

entities (tous les POPO (Plain Old PHP Object :P))

test

web

services

entities

resources

i18n

js

css

images

external (librairies tierces "lourdes")

doc (PHPDoc)

index.php

Ma première question, la plus importante, est : qu'en pensez-vous ?
Je ne cherche pas à savoir si tel ou tel framework fait déjà le boulot ou pas... je veux juste savoir ce qui est améliorable dans l'architecture que j'utilise.

Ma deuxième question est simple, mais la solution à envisager sans doute compliquée: là où je fais mon stage, l'application est basée sur SOA...
L'idée me plaît beaucoup. J'aimerais pouvoir partager plusieurs services communs à toutes les applications PHP que j'écris (Log - pas login hein, I18N) sans avoir à les réintégrer en permanence...
Bref ma question est: existe-t'il un moyen simple (non pas facile mais simple) de partager plusieurs services entre des applications php ?

Merci d'avance,
Rolf

Sans voix n'est pas le mot. Plutôt sans idée, sans intérêt :mrgreen:

L'architecture du files sys ne fait pas l'application. Ca y contribue, certes, mais plein d'autres facteurs sont importants.
La sécurité, par exemple. Genre on dirait que index.php est à la racine de Dummy. Un utilisateur peut-il accéder directement à http://url/main/test/services ?

Alors sinon le moyen simple de partager plusieurs services entre appli, au niveau du code, est de mettre la partie qui relève de la "librairie" en dehors du "document root". Ces fichiers sont chargés à la demande quand on en a besoins.

J'ai peut-être oublié de préciser certaines choses :)

index.php est l'unique point d'entrée des requêtes utilisateurs (ou controllers/*).
Pour l'instant, j'applique MVC ds ce fichier de façon toute bête: un gros switch, puis inclusion du gabarit.
L'utilisateur n'est pas censé accéder aux autres ressources directement.

Mes questions sont plutôt liées à la configuration, dans la mesure où je ne veux que quelques ressources exposables.

la structure chacun a la la sienne, du moment qu'il y a une coherence ca le fait. Je ferais une petite remarque toutefois :)
si j'etais toi, je metterais index.php, img, css, js etc.. dans un autre dossier (appellons le public_html ou wwwroot). Ce qui te donnerais l'archi suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

Dummy webapp config   config.php   inc   Autoload.inc.php (configuration de l'autoload)   functions.inc.php (toutes les fonctions utilitaires de l'appli)   constants.inc.php (toutes les constantes)   controllers (éventuellement d'autres contrôleurs)   main   src   web (toutes les classes liées à l'interface utilisateur)   services   entities (tous les POPO (Plain Old PHP Object ))   test   web   services   entities   resources   i18n   external (librairies tierces "lourdes")   doc (PHPDoc)   public_html   js   css   images   index.php

---

Quel est l'interet ?
- L'interet premier c'est de sortir la logique de la partie accessible depuis le web de ton server. Ce qui va en resulter une plus grand securite (personne ne pourra acceder a tes fichier classe, fonction etc..).
- Un gain en maintenabilite. Tu corrige un bug, on va dire que tu as du modifier plusieurs classes. Le jour de la mise en prod du correctif t'es malade, ton collegue doit le faire mais sais pas quels fichiers t'as edite. Que fait-il ? il copie comme un boubourse l'integralite du site de development en prod et par la meme occasion, les images de test, le cache du test etc...(ca arrive aussi quand on a une mauvaise memoire). Alors que si la parti "web" avait ete separer de la partie metier, il aurait juste copier la parti metier et roule ma poule.
- Un gain en scalabilite (ca se dit ?). Demain ton site grossie tu dois mettre en place un cluster. c'est cool de ce dire qu'on peut mettre tout ses css, img etc.. sur un autre serveur, cree un symlink vers le mount de ce serveur et d'avoir son contenue mis a jour sur tout les serveur en temps reel (surtout protique quand on doit enregister des images envoyer par les utilisateurs et qu'ils changent de serveur en route).

Enfin voila on avis sinon c'est coherent, c'est cool je pense

ta remarque a du sens en effet (dans la mesure où je comprends le franglais :wink:)... j'ai toujours eu du mal à bien différencier ce qui devait être exposable de ce que devait pas l'être...

desole ca fait trop longtemps que je vis loin de la france et surtout que je n'utilise plus le francais comme langue de travail :aie: