Discussion :

[lorem47]

Bonjour à tous,

Je me suis mis à Symfony2 il y a peu de temps. J'ai lu beaucoup de documentation (sur le site officiel) et également un livre (Symfony2 , Développez des sites web PHP structurés et performants de Bilal Amarni) mais je n'ai pas trouvé la réponse à cette question : comment organiser mon projet pour gérer correctement un front office et un back office ?

Bien sûr, je peux le faire. Mais quelle est la meilleure façon de faire ? Quelles sont les best-practices à ce sujet ?

Voici en détail ce que j'aimerais avoir :

1. un front-office avec :
   
   • un layout spécifique
   • des assets (CSS, JS, images) non partagés avec le back
   • un user de base de données avec des droits spécifiques au front (par exemple, pas de "delete" autorisés, lecture de certaines tables interdites, etc.)
   • une gestion d'utilisateurs (certains utilisateurs peuvent se connecter au front mais pas au back, et les utilisateurs du back peuvent tous se connecter au front)
   
   
2. un back-office avec :
   
   • un layout spécifique
   • des assets (CSS, JS, images) non partagés avec le front
   • un user de base de données avec des droits spécifiques au back (par exemple, "delete" autorisés, etc.)
   • une gestion d'utilisateurs (certains utilisateurs peuvent se connecter au front mais pas au back, et les utilisateurs du back peuvent tous se connecter au front)
   
   
3. des modèles et configuration partagés entre les deux parties précédentes
   
   • la base de données étant commune, je voudrais que mes "entities" Doctrine soit communes
   • les routes du front devraient être accessible depuis le back (par exemple, pour générer des URL dans des emails, via les routes)
   
   

Sachant tout cela, quelle répartition me suggérez-vous ?
Dans des bundles séparés ? (pourtant la documentation officiel préconise d'en avoir un seul nommé AppBundle)
Dans des projets différents ? Dans, ce cas, quid des modèles et configuration partagés ?
Autrement ?

Merci d'avance pour vos réponses.

[dukoid]

HUGH !

éternelle question que voici et personne ne peut vraiment répondre car cela dépends de paramètres :

2 grandes raisons pour séparer le back sur un projet et le front sur un autre projet :
1)
par exemple si tu veux faire tourner un projet frontend sur un serveur et un projet backend sur un autre serveur (pour X raisons par exemple pour de la perf ou de la maintenance)

2)
Sur le front il faut limiter au maximum le moindre risque.
* En installant X bundles tiers comme sonata sur le back et d'autres bundles pour le front ce qui fait que pour la maintenance ou la mise à jour de ces bundles il peut y avoir des risque de conflits.
* Pour x raisons, faire tourner le front sur une version de sf et le sur back sur une autre version de sf
* d'un point de vue programmatique si tu fais des modifs sur le back il y a moins de risque de générer des régressions sur le front et vice versa.



sinon au minium il faut séparer avec un bundle frontend et un bundle backend car se sont 2 choses différentes qui ont un seul point commun la base de donnée.
dans l'APP je met peu de choses , que les trucs communes nécessaire entre les 2 bundles comme les fichiers de conf etc...

[lorem47]

Salut dukoid et merci pour ta réponse !

J'aime bien l'idée de séparer en deux projets distincts car, pour moi, ce sont bien deux "applications" différentes.
En revanche, où est-ce que tu positionnerais les éléments communs ?

En ce qui concerne les entities Doctrine, je pensais éventuellement créer un bundle que j'incluerais dans les deux projets. Qu'en penses-tu ? Y-a-t-il mieux à faire ?

Au sujet des routes, je suis un peu plus dans le flou... Je ne vois pas vraiment comment générer une URL du front office depuis le back office. As-tu déjà mis en oeuvre une solution à ce type de problème ? Si oui, comment ?
(Cas d'usage : je veux envoyer un email à client depuis mon back office, et cet email contient des liens vers des pages de mon front office.)

Merci encore !
A+

[dukoid]

surtout ne pas inclure un même bundle dans 2 endroits différents. il faut que le bundle soit en commun.

pour tes autres questions ça doit être réalisable, je n'ai jamais fais ça, surement que d'autres personnes pourrons te répondre.
pose clairement la question dans un autres message...

[goabonga]

Pourquoi ne pas penser api rest sso oauth et donc une application maitre et deux clients ?