Passage d'une application web vers Symfony2 : pour quelle architecture opter ?

Bonsoir,


Après avoir développé une application web en php "brut" et jQuery mobile (pour accès sur mobile, donc) pour un client (gestion de sa comptabilité et de ses stocks), j'ai l'occasion de proposer cette appli à d'autres clients.
Dès lors, j'aimerais passer à Symfony2 pour rendre la chose plus structurée et permettre une meilleure maintenance.

Seulement voilà, je ne sais pas quelle architecture adopter pour distribuer l'appli web, sachant que chaque client désire avoir une base de donnée qui lui est propre (données critiques oblige) et que, même si l'application web est la même pour tous mes clients, il se peut que certaines diffèrent légèrement (module personnalisé, voir ajout d'un module pour un client particulier).

EDIT: Petite précision supplémentaire: chaque client devrait avoir un dossier "facture" qui lui est propre, et où il pourrait retrouver ses factures en PDF.


J'aimerais avoir l'avis éclairé de quelques personnes sur comment je dois m'y prendre.
-Dois-je opter pour une instance Symfony unique, où chaque /app serait un client (ce qui implique une bdd différente pour chaque app :/).
- Une instance Symfony par client, complètement indépendante des autres (mais quid de la mise à jour de l'appli, vais-je devoir la faire manuellement pour chaque client ?)
-Ou carrément une app unique pour tous les clients, et où chaque utilisateur accéderait à sa propre bdd ? (possible ?)


Voilà, j'aimerais éviter d'aller droit dans le mur, en me rendant compte que l'architecture pour laquelle j'ai opté n'est pas optimisée pour mon cas.

Je vous remercie d'avance pour vos avis et reste dans les parages pour vos questions éventuelles :) .


Bonne soirée,

Colmea

Bonjour,

Comme je vois que mon post n'a pas beaucoup de succès, je vais simplifier ma question.
Après quelques recherches, il semble que la solution de plusieurs bdd pour un même projet sera difficilement maintenable (surtout si il y a une bdd par client).

Je pense donc me diriger vers une instance de Symfony par client.

Mes deux questions sont donc:
- Est-ce que Symfony2 gère bien le fait d'être avec d'autres instances de Symfony sur un même serveur ?
- Y-a-t-il une solution plus ou moins rapide pour mettre à jour plusieurs serveurs de production à partir d'un serveur local de dev unique (en gros que les mises à jour que je fais en environnement de dév se répercutent sur TOUTES les instances de symfony). J'imagine que je vais devoir bricoler un truc, mais est-ce faisable ?


Je vous remercie d'avance, en espérant avoir quelques avis :)

Bonne journée à vous,

Colmea

Bonjour,

Citation:

---

- Est-ce que Symfony2 gère bien le fait d'être avec d'autres instances de Symfony sur un même serveur ?

---

J'ai plusieurs applis identique sur le même serveur, ça ne pose pas de problème, (hormis quelques problème au début, sans doute du au cache apc).
dans chaque répertoire d'install on duplique tout les répertoires sauf vendor qui est un lien symbolique.
On pourrait également faire un lien symbolique vers src, mais je trouve que ça ne simplifie pas les choses si tu ne veux mettre à jour qu'une install.

Citation:

---

- Y-a-t-il une solution plus ou moins rapide pour mettre à jour plusieurs serveurs de production à partir d'un serveur local de dev unique (en gros que les mises à jour que je fais en environnement de dév se répercutent sur TOUTES les instances de symfony). J'imagine que je vais devoir bricoler un truc, mais est-ce faisable ?

---

une mise à jour ça peut se résumer à lancer quelques commandes (git pull, app/console doctrine:migrations:migrate, app/console cache:clear --env=prod)
donc ça peut toujours s'automatiser via des script shell.
tu peux regarder aussi du coté de http://capifony.org/

Ce que tu veux faire c'est développer un système SaaS donc ;)

C'est un sujet très intéressant et très moderne :)

2 petites lectures :
http://advancedphpsolutions.com/blog...n-development/
http://blogs.msdn.com/b/gianpaolo/ar...06/544354.aspx

Citation:

---

Envoyé par ovh

Ce que tu veux faire c'est développer un système SaaS donc ;)

---

Exactement :) Je m'empresse de lire ces deux articles, je vois qu'ils ont +/- les même interrogations que moi :)

Citation:

---

dans chaque répertoire d'install on duplique tout les répertoires sauf vendor qui est un lien symbolique

---

D'accord, donc un seul et même vendor pour tous les utilisateurs, c'est plus intéressant en effet. Je pensais effectivement à quelques commandes pour mettre à jour. Si tu me dis que c'est facilement faisable, c'est parfait.

On perd un peu le côté "une seule application pour tous mes clients", qui serait une solution facilement maintenable car une seule màj à faire, mais comme tu le dis, si on désire faire un màj pour une seule application, ou la personnaliser, c'est mieux de séparer le src.

Merci pour vos remarques/conseils. Si quelqu'un veut rajouter quelque chose avant que je me lance définitivement, c'est le moment :p

Bonne soirée à vous,

Colmea

Citation:

---

Envoyé par Colmea

...
Merci pour vos remarques/conseils. Si quelqu'un veut rajouter quelque chose avant que je me lance définitivement, c'est le moment :p

Bonne soirée à vous,

Colmea

---

Bonjour,

J'ai comme toi développé sans framework et je me met à Symfony.
Je suis bien incapable de t'aider pour l'architecture, mais ce qui me parait certain c'est de n'avoir qu'une seule base.
Pour avoir développé, refait, maintenu une application qui avait plusieurs centaines de clients différents, je suis sur de la chose.
Cela implique que la plupart de tes tables possèdent un id pour le client.
Ensuite en fonction des particularités de certains clients tu choisis de faire apparaître ou non certains aspects.
En fait, c'est la conception de ta base qui devrait t'apporter la solution.
Si tu vois que tu peux t'en sortir simplement avec un id et quelques tables de plus alors il faut une seule base.

Bon courage

Bonjour,

merci pour ta réponse.
Je suis tout à fait conscient des avantages d'une seule et unique base de donnée. J'ai toujours fonctionné ainsi, et mon projet pourrait techniquement très bien se faire avec une bdd.

Malheureusement, c'est la seule condition que je demande: avoir une base de donnée différente pour chaque utilisateur. Premièrement parce que, comme je l'ai dit plus haut, ces données sont très confidentielles, et nous voulons garantir la meilleure sécurité pour nos clients. On est bien d'accord, il n'y a théoriquement pas plus de risques qu'ils soient sur la même bdd ou pas, mais niveau marketing ça change tout.
De plus le problème de plusieurs bdd se poserait un jour ou l'autre puisque nous ne serons pas capable d'accueillir tous les clients sur un seul serveur.


On développe actuellement le projet sans avoir vraiment fait notre choix sur l'architecture à adopter. Je reviens vers vous à la fin du développement si on arrive pas à se décider :)

Merci à vous,

Colmea