Avis sur architecture

**Rolf-IV** · 15/12/2009, 21h37

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

))

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

**metagoto** · 16/12/2009, 18h57

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

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.

**Rolf-IV** · 16/12/2009, 19h36

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.

mon_nom_est_personne · 17/12/2009, 03h29

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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