Bonsoir,

Il me paraissait plus "normal" de ne réserver le code des contrôleurs que pour la gestions des routes de mon applications.

Ainsi, je m'interdisais l'utilisation de DAO dans les contrôleurs, pour externaliser l'ensemble dans des classes métiers.

Mais je me disais que :

• mes classes métiers dépendent de Jelix puisqu'elles utilisent jDAO. Donc elles ne sont pas particulièrement portables
• à vouloir externaliser les communication BDD, je me retrouve avec des classes métiers parfois toutes petites, avec juste une ligne pour faire appel à un DAO. C'est un peu bête, autant le faire depuis le contrôleur,
• et puis, l'emploi des formulaires obligent à utiliser des DAO dans les contrôleurs, pour faire par exemple des saveToDao.

En fait, (et c'est un problème d'architecture, pas propre à Jelix) j'ai du mal à discerner ce qui devrait être du rôle du contrôleur. J'ai du mal à trouver la limite.

Faut-il intégrer le code métier, les DAO, dans les contrôleurs ?

Faut-il y placer des textes (assignations de variables de templates), ou des codes en laissant la charge au template d'afficher le texte correspondant au code ? EN fait, j'avais des contrôleurs avec pleins de texte, y compris du texte html. Puis, en décortiquant le code du forum de Foxmask, je me suis srendu compte que ses contrôleurs n'avaient pas de contenu de texte devant apparaitre dans les templates...

Bref, je suis un peu pommé, là. Pouvez-vous m'aider à y voir plus clair ? Merci par avance.

Bonjour,

Oui c'est clair,

Avec ton discernement tu as les clefs entre tes main ;)

Effectivement selon les cas ; pour peu de code ; produire une methode dans une classe métier est dérisoire.

Une classe métier n'est portable que pour d'autres appli jelix si on utilise des "verbes" qui lui sont propres (jDao/jDb, etc)

Sinon en guise d'exemple voici le Controleur 'Posts' de HaveFnuBB et la classe metier Hfnuposts où j'ai exactement décorrélé le "metier" du controleur.

cdt.

Salut,

Oui, j'ai passé pas mal de temps sur tes sources :-)

Par contre, selon les modules, il y a plus ou moins de logique métier dans tes contrôleurs.

Mais mon appli étant relativement petite, je me demande si je ne me prends pas la tête pour rien, car je crois que mes contrôleurs pourraient très bien contenir le peu de logique métier. Les fichiers correspondant n'auraient pas énormément de lignes de code.

Je recherche (en fr) une sorte de guide des bonnes pratiques, et ce n'est pas facile. J'ai pleins de livres sur MVC, mais ils ne détaillent pas cet aspect.

Un cas concret : j'ai un formulaire qui permet d'éditer une rubrique, ou d'en créer une nouvelle. Je veux que, selon les cas, apparaisse "Modification d'une rubrique" ou "Ajout d'une rubrique" au-dessus du formulaire.

Dans mon contrôleur, selon qu'un ID existe, je définis une variable de template "mode" à (pas de multilinguisme) :

• "<strong>Modification</strong> d'une rubrique" ou
• "<strong>Ajout</strong> d'une rubrique"

Mais est-ce propre ?

Ou faudrait-il mieux définir une variable "mode" à "edit" ou "add", puis faire un if else dans mon template pour afficher la phrase correspondante ?

Et pour en revenir aux DAOs, vous paraît-il aberrant de les utiliser dans des contrôleurs ? Est-ce "une bonne pratique" ?

Journée triturage de cerveau...

Pour moi, un dao, c'est plus ou moins une classe metier non ? Si le dao te fourni exactement ce que tu veux, il faut rester pragmatique, et l'utiliser directement, sans faire de classes metiers avec une seule ligne.

Alors certes, si plus tard, l'appli évolue et que la complexité s'intensifiant, il te faudra peut être faire une classe métier qui cachera, du point de vue du controleur, la "complexité" du code metier, donc tu devra modifier tout tes appels de daos par des appels à ta classe metier. (ce que tu n'auras pas à faire si tu tout de suite une classe métier, et encore... pas sûr, car les évolutions t'ameneront à rajouter des arguments à tes methodes de ta classe etc.. )

Enfin bref, je ne pense pas que ce soit "sale" d'utiliser un dao directement dans un contrôleur. Par contre il est clair : éviter du code métier dans le contrôleur. Le contrôleur (Controller) n'est là que pour récupérer les données (appel de la couche Model), et les injecter dans la réponse (View), en fonction evidement de paramètre d'url ou autre (d'où son nom de controleur, il contrôle la vue en fonction de contextes).

faudrait-il mieux définir une variable "mode" à "edit" ou "add", puis faire un if else dans mon template pour afficher la phrase correspondante ?

Bien sûr. Le contrôleur ne doit pas manipuler lui même le contenu de la vue. il doit juste injecter les données qui permettent à la vue de produire le résultat finale. Imagine que tu veux réutiliser le même template dans une autre action ? Il faudrait, dans toutes ces actions, que tu assignes "mode" avec du contenu html ? vaut mieux que ce html soit dans le template. c'est sa place.

parfois un peu de pragmatisme permet d'éviter d'alourdir la mécanique

Tout à fait. Jouer les puristes, c'est bien, quand c'est utile. Pour des choses ultra simple, c'est inutile voir néfaste = plus de code à écrire et à maintenir, complexifie justement la maintenance, et allonge les temps d'executions (plus il y a de classes ou de methodes à charger/à charger, plus ça prend de la mémoire et du cpu).

PHP est suffisement souple pour pouvoir évoluer, si les besoins se font sentir, vers du code plus "pure" (et c'est bien).

(ça me fait bien marrer ceux qui font des méthodes de type getter/setter quand il s'agit simplement de manipuler une propriété protégée/privée)

La Dao le fait de facto puisque les Property possède des datatypes.

Ah bon ? Pourtant, cela permet de valider les données avant de les affecter aux propriétés.

En disant "quand il s'agit simplement de manipuler une propriété protégée/privée", je voulais parler d'une simple affectation ou lecture.

faire

   function getValue() { return $this->value; }
   function setValue($val) { $this->value = $val; }

Je trouve ça ridicule en PHP, tellement ça bouffe de la mémoire et du processeur par rapport à un accès direct à la propriété.