Architecture MVC pour un backend d'administration

Je continue mon aprentissage de MVC et je me pose des questions sur l'architecture d'un site avec back-office d'administration.

Je vais essayer de mettre en place un exemple :
J'ai une liste d'objets en base de données

Dans la partie publique, je dois pouvoir lister ces objets et visualiser la fiche d'un objet

Dans la partie admin, je dois pouvoir ajouter un objet, en supprimer ainsi que modifier sa fiche.

Quelle serait les appels nécessaires, et donc les controllers et actions qui leur seront liés ?

La partie publique, assez facile :

• listing des objets : monsite.fr/objets/liste
• visualiser un objet : monsite.fr/objets/view/id/4

La vraie question est pour la partie admin. Pour l'instant, je m'oriente sur quelquechose comme ça :

• listing des objets : monsite.fr/objets/liste avec des tests sur l'utilisateur pour savoir s'il est admin. Si oui, afficher les liens de gestion
• ajouter un objet : monsite.fr/objets/formulaire
• modifier un objet : monsite.fr/objets/formulaire/id/4 la présence de l'id indique qu'il s'agit d'une modif et non d'un ajout
• supprimer un objet : monsite.fr/objets/supprimer/id/8

Cela vous semble-t-il correct ?

Ne devrais-je pas plutôt créer un controller d'administration pour aboutir à une url de ce style : monsite.fr/admin/modifierobjet/id/5 ?

Ou encore un module d'administration ?
Qui serait donc accédé avec une url monsite.fr/admin/objets/modifier/id/6 mais cela m'oblige à redéfinir un controller objetsController dans le module d'admin, non ?

Une approche à la REST voudrait que l'url de la ressource (l'objet) soit la même que l'on veuille l'afficher, le modifier ou le supprimer. L'action à prendre en charge est dictée par le type de requête http (GET, UPDATE, DELETE).
Difficile à mettre en place pour l'instant car les browsers ne gèrent généralement que GET et POST

Perso, j'ai plutôt tendance à opter pour des urls de type "/admin/objets"
avec la partie admin dans un module en tant que tel.
Mais le principe de routing et de rewrite n'exclut pas d'avoir une simple url "/objets" tout en redirigeant en interne vers un module différent du module publique (ou différent d'un controller publique)

Hello, étant parti sur une construction MVC complètement modulaire on a choisi de différencier les controllers public et ceux d'admin, ça a le gros avantage de bien se caler avec une gestion d'acl basée sur les modules/controller et action déclarés en base de données.

Je suis également pour l'option 2, c'est d'ailleurs celle que j'adopte pour mon site.
Le premier point est une histoire de sémantique, le second pour une histoire d'acl, c'est plus facile de dire "rang admin -> acces module admin" que dire "rang admin ->acces a certaines action dans certains controller de certains module"

Mais cela sous-entend de "dupliquer" certains controllers.

Dans mon exemple, il faudrait un objetController dans le module par défaut ainsi qu'une controller du même nom dans le module d'admin.
Ca ne vous dérange pas ? (vraie question, aucune ironie)

"Dupliquer" ? Pas vraiment, c'est juste le même nom. Tu peux considérer ça comme un espèce d'espace de nom pour les contrôleurs ^^

Ca ne me dérange pas, si ça te gêne, rien ne t'empêche de l'appeler AdminObjetController ;) Cela dit, quand tu va l'appeler via l'aide de vue d'url, ça fera un peu répétition :

Code:

---

1 2 3

$this->url(array(module=>'admin',controller=>'adminobjet',action=>'editobjet')); //Au lieu de $this->url(array(module=>'admin',controller=>'objet',action=>'edit'));

---

C'est plus lisible non ?

Oui je parlais juste de duplication au niveau du nom.
Mais s'il s'agit des pratiques, ça ne me dérange pas. Le but du jeu étant d'utiliser des normes communes afin qu'une autre personne puisse debugger mon code.
A priori, chercher un nom de controller à plusieurs endroits me semblait plus compliqué, mais s'il s'agit de normes plus ou moins connues, le problème est moins grave.

Merci ! :ccool: