Découpage des controllers

Bonjour :D

J'aimerais savoir comment vous déterminez le périmètre et le contenu de vos controllers ? Plus clairement, comment décidez-vous du découpage de vos controllers, c'est-à-dire ce qui va appartenir plutôt à un controller qu'à un autre ? En fonction de vos IHM ? En fonction de la bdd ? En fonction de la couche model ?

Pour prendre un exemple concret, j'ai une interface avec un menu découpé selon les principales fonctionnalités de mon application, en voici un extrait qui concerne la gestion de dossiers et de comptes (objets métier de mon appli) :
http://img513.imageshack.us/img513/7866/menuno5.jpg

J'ai commencé à faire le squelette des classes de mon framework MVC, et je me penche sur le cas des controllers. J'ai hésité puis j'ai crée pour l'instant 2 controllers :
DossierController et CompteController.

Qu'en pensez-vous ? Comment vous y prenez vous de votre côté ?

Merci d'avance ! :king:

Tout dépends de l'application que tu veux coder. L'important est de découper ton application en "grandes catégories" qui vont correspondre à tes contrôleurs. Par exemple : Accueil (Index), Gestion des membres (Members), Messagerie interne (PrivateMsg), Système de news (News), Espace de téléchargement (Downloads), etc.
Vouloir faire correspondre Un model à Un contrôleur n'est pas efficace, car souvent les models doivent êtres liés pour remplir les tâches que l'on veux (par exemple l'accueil sera sans doute lié aux news, la messagerie privée aux membres, ...).

Merci pour ta réponse Psykocrash ;) Je pense que je suis partie sur ce principe de "grandes catégories". Je verrais si je dois affiner un peu ensuite ou pas !

Je part de la spécification générale de mon application pour déterminer les packages (sens UML). Ils vont donner les modules de l'application.

dans les spécifications détaillés je vais me retrouver dans chaque packages de nouveau package qui représente des unité applicative. en ce sens que ce qu'elle manipule représente un seul et même concept. l'interface de ce package et plus ou moins l'ensemble des action que l'on peut faire sur ce package généralement dans ce package se trouve plusieurs classes du modèle manipulées par cette unité. c'est ainsi que je détermine mes contrôleurs.

pour aller plus loin la conception à partir de là va déterminer les classer métier (le modèle) de l'application.

un bon moyen de déterminer la notion d'unité fonctionnelle est de voir quels les élément du modèle qui se retrouve dans plusieurs untiée. normalement ces éléments doivent obligatoirement apparaître dans l'interface de chaque unité où ils apparaissent. si ce n'est pas le cas c'est qu'on a une fuite d'étanchéité de l'unité. et que donc nos unité ne son pas si indépendante que ça. il est probable que la conception est à revoir.

de même la frontière des modules doit clairement définir les éléments qui sont à l'interface.

l'interface utilisateur ne dois pas entrer dans le choix des contrôleurs mais au contraire en découler. des le contrôleur qui définit quoi afficher. bien que parfois pour faciliter le travail certains regroupements voient le jours.

La base de donnée ne doit elle absolument pas entrer dans la conception du contrôleur. la base doit être conçue pour répondre au besoin du modèle. Il n'y a à priori aucunes raison pour que le modèle de données de la base soit le reflet du modèle objet de l'application. le modèle de donnée doit être conçu pour servir au mieux le modèle applicatif. et cela nécessite une conception à part entière.
la distance entre le modèle de donnée et le modèle application est un premier éléments qui rends la conception des contrôleurs difficile à partir de la base. mais il y a aussi une différence entre ce qu'est le modèle de donnée applicatif et l'usage qu'on en fait dans l'application. et cette différence rend le découpage en contrôleur encore plus difficile à partir de la base.

A+JYT

Merci à toi d'avoir pris le temps de me répondre Sekaijin ;)