Version imprimable
Bonjour
Suite à une petit question sur le forum, on m'a indiqué que c'est bien de mettre ses fichiers structure (accès base, MVC...) plus haut dans la racine du site...
Si j'ai 3 sites
www/site1
www/site2
www/site3
cela veut dire que je pourrais mettre des fichiers communs au 3 sites au dessus de la racine s'ils utilisent tous certains scripts communs (modèle, vue, contrôleur) plutôt que de recopier ces fichiers dans les 3 sites
Bonne ou mauvaise idée
Bonjour,
Tu te poses beaucoup trop de question...
Pourquoi tu ne commencerais pas à faire un petit site test ?
Ça te permettrait d'avancer concretement, et de régler un problème après l'autre.
Justement c'est ce que je fais et à chaque étape tente de me poser le maximum de questions...
sinon je peux ne pas me poser de questions et rester sur wordpress lol mais sur wordpress je m'en posais déjà :) et c'est grace a toutes ses questions que j'ai décider d’évoluer vers du fait maison bio
Pas pour le coté bio, mais justement pour apprendre et trouver des réponses à ma curiosité :)
Mais si t'as pas la réponse c'est pas grave ;)
La question n'est pas si c'est faisable car je me doute que OUI
mais c'était avoir un avis éclairé pour savoir si c'était une bonne idée...
cela peut être faisable... mais ne pas être une bonne idée de faire ouvrir solliciter le même fichier, ou le même script par plusieurs sites à la fois....
Donc, je pose la question pour avoir des avis de personnes qui on du recul et de l'expérience (une vision globale) pour avancer à mon petit niveau si possible dans le bon sens.
Oui, d'une façon générale, ça paraît de bon sens de faire un dossier share ou lib à la racine de ton serveur pour toutes les librairies partagées, qu'elles soient internes ou externes.
Rien ne sert de stocker n fois une librairie ou classe que tu ne modifies pas à chaque appli. Ces briques de code là, qui doivent être suffisamment abstraites, seront ainsi paramétrables depuis l'appel de ton site précis.
Les architectures de site, c'est vraiment des choix individuels.
Tu as peut-être intérêt justement à préciser :
lib
---externe
------phpexcel
------phpword
------jpgraph
------tcpdf
---interne
------connexion_db
style
---externe
------jquery.css
---interne
------machin.css
js
---externe
------jquery.js
---interne
------machin.js
www
---monsite1
------config.php
------class
------style
------js
---monsite2
------config.php
------class
------style
------js
---monsite3
------config.php
------class
------style
------js
Au dela de la non redondance de code, ça te permet aussi de poser des droits apache sur le répertoire lib très différents du répertoire www, qui est public et donc beaucoup plus permissif.
Ca te permet de coder une couche abstraite et logique d'accès à tes include...
Reste à réfléchir dans cette architecture globale comment tu intègres le design pattern MVC...
hum ça c'est une réponse qui me plait (constructive et argumenté) lol
Question sollicitation des fichiers (lib, class) si X sites interroges le même fichier cela pose-t-il un problème d'accès (entonnoir) saturation...
De mémoire à l'époque j’enregistrai des infos dans des fichiers flats et on m'avait indiqué que je devais gérer le problème des écritures multiples... (d'ou les bdd).
En lecture ce problème n'existe pas ?
Oui, j'ai été débutante il y a dix ans, et anxieuse à l'idée d'utiliser des DB qui me paraissaient bien complexes (et qui le sont), j'ai eu la même envie que toi.Citation:
De mémoire à l'époque j’enregistrai des infos dans des fichiers flats et on m'avait indiqué que je devais gérer le problème des écritures multiples... (d'ou les bdd).
Il n'y a pas à rougir de vouloir faire simple.
Mais il n'y a pas que pour ces histoires de bonne gestion d'utilisateurs multiples simultanées que les db sont perfomantes.
Il y a aussi pour la conception merveilleusement factorisée des différentes tables et des relations entre elles. Ce qu'un fichier csv ou excel ne peut pas gérer.
Et ce qui permet ensuite de faire des requêtes d'une exactitude merveilleuse ! De prévoir toutes les évolutions ultérieures de l'appli sans tout casser côté base !
Aujourd'hui, je bataille ferme parfois contre des MOA qui me disent, tu n'as qu'à reporter nos excels dans une base et zou, on avance... Sans se rendre compte que la modélisation en base avec les formes normales ne peuvent pas être avalées telles quelles par la base, sauf à nier l'utilité des listes de nomenclature, des relations de tables entres elles, tout à fait essentielles. Leurs excels en version SQL deviennent des requêtes, certainement pas une table qui serait faite de bric et de broc !
J'aurais tendance à te répondre que non mais 1) je ne sais pas les masses qui fréquentent ton site. Moi, j'ai des sites très utiles mais qui attirent les salariés de mon entreprise, pas le grand public. Ma plus grosse appli n'a que 1000 utilisateurs potentiels, ce qui fait dans les 200 utilisateurs différents quotidiens toute l'année. Je n'ai donc jamais de souci de montée en charge de ce côté. C'est plutôt les données traitées en base qui peuvent être très volumineuses. 2) Et puis, dans le cas de librairies partagées par toutes tes applis, c'est davantage de l'exécution de fichier, que de la lecture. 3) Enfin, bon, je suis curieuse de voir la réponse d'experts car il y en a ici.Citation:
En lecture [de fichiers type librairies partagées sur plusieurs applis] ce problème [de saturation car trop d'utilisateurs] n'existe pas ?
Comment tu conçois l'intégration de l'architecture MVC dans ton architecture share ? C'est pas si simple et tu ne m'as pas répondu. Et c'est pareil, j'aimerais que des experts en MVC nous disent si c'est 2 architectures qui mélangent 2 paradigmes incompatibles, on ne sait jamais. Je ne voudrais pas te souffler des bêtises. Car moi, pour mes projets de taille moyenne qui tiennent la route, j'ai intégré j'espère la philosophie globale de la séparation MVC, sans faire de purisme car mes projets n'ont pas besoin d'une extrême séparation des genres...
Encore une fois, je crois qu'il faut garder du bon sens, et se dire : Ca c'est un vrai plus pour ce dont j'ai besoin, j'adopte et j'adapte, plus l'esprit que la lettre. Car je n'aime pas non plus aller chercher des obésiciels pour écraser une mouche. ;)
Et comme disait mon ancien DSI : "Bien sûr, on a des exigences qualité, mais on n'envoie pas non plus des fusées sur la lune !". :mouarf:
Donc j'adopte PDO, ou j'adopte PHP objet sans être parfaite mais sans violer non plus le paradigme de fond toutes les 5 minutes, enfin j'adopte des conseils MVC, plus particulièrement, je sépare surtout View et Controller, pour les modèles, sur les petites applis, je ne fais pas toujours de classes dédiées aux Modèles, qui sont parfois très très basiques. C'est pour ma part souvent la nuit via des crons que je fais remonter des bases RH vers la base locale les éléments de gestion qui m'intéressent pour telle ou telle appli, que j'opère les traitements qui intéressent ma MOA. Ainsi, quand ils en sont à naviguer, tout est fluide soit que je les fais accéder à des vues simples, soient que les vues sont vraiment trop lourdes et que je les ai transformées en tables matérialisées.
waou ça c'est encore une fois de la réponse... j'adore...
Mais pour ma part étant bloqué par mon hébergeur (mutualisé) je ne vais pas pouvoir continuer sur ce chemin et revoir mon angle d'attaque.
Si je définie ma racine à www/public il m'interdit de remonter plus haut que ma racine (open_basedir) grrrrrrrrrrrrrr
Je me demandais pourquoi WORDPRESS laissait ses fichiers sensibles à la racine du site et non pas un cran avant le fichier index (racine) et bien comme WP doit pouvoir s’installer chez n'importe quel hébergeur (compatibilité) cela évite les problèmes de blocage (pour les hébergements mutualisés).
Par contre tu abordes un sujet qui m’intéresse....
Car j'aimerais pouvoir faire des calculs type Trésorerie directement sur une appli web plutôt que sur excelCitation:
qui me disent, tu n'as qu'à reporter nos excels dans une base et zou, on avance...
Une Bdd n'est pas un Tableur, je dois prendre le sujet dans quel sens
Un fichier excel peut contenir des centaines de cellules de calcul... avec des calcul intermédieras (juste pour si retrouver)...
PHP sait calculer / Mysql sait stocker,
Mais normalement on doit stoker des données non redondantes et non liées à un calcul....
Comment structurer et retrouver une logique excel au travers d'une app PHP/Mysql ???
Faudrait qu'on parte d'un de tes excels pour mettre les mains dans le cambouis...
Certes, pour la modélisation et pour constituer tes tables.Citation:
Mais normalement on doit stoker des données non redondantes et non liées à un calcul....
Mais après, rien ne t'interdit de stocker tes formules de calcul dans des vues, qui ne sont jamais que des structures de requêtes que tu pérennises via les tables d'administration de ta base.