Discussion :

[Yogui]

Bonsoir à tous

Julien Pauli nous propose un article sur les modèles en architecture MVC dans Zend Framework :

Dans un modèle MVC, on a tendance à en demander trop aux contrôleurs. Ceux-ci doivent faire quelques lignes seulement, or on retrouve souvent des responsabilités qui leur sont attribuées à tort : Création des modèles et création des formulaires notamment. Nous allons voir ici comment donner vie à un modèle, et comment décharger le contrôleur tout en simplifiant son API.

http://julien-pauli.developpez.com/t...les-puissance/


Qu'en pensez-vous ? Pour ma part, je ne suis pas sûr d'être convaincu qu'un "objet métier" soit en premier lieu un objet de la base de données. Pourquoi ne pas utiliser un modèle formulaire comme "objet métier", dans la mesure où les formulaires disposent de toute la chaîne de validation et de filtres ? Cela me semblerait cohérent.

En tout cas, merci pour cet article

[Alexandre T]

Bonjour,

Je réagis à cet article, car une application que j'ai développée avec Zend fonctionne de cette façon. L'application étant basique, cela fonctionne très bien.

Par contre, je dispose d'une autre application très sensible à la charge. Je dispose de tronçons autoroutiers. Chaque tronçons autoroutiers est bidirectionnel et chacun est relié aux deux sens de circulation.

J'ai quelque chose de la sorte donc :
te_troncon_tro (tro_id, sen_id_1, sen_id_2, tro_lib,....)h
te_sens_sen (sen_id,sen_lib,...)

Lorsque je charge un tronçon, j'ai systématiquement besoin de charger les deux sens. Et en utilisant les pattern de l'exemple, ça marche. Seulement au niveau des requêtes rien n'est optimisé.

En analysant les requêtes passées à la base, je remarque que j'ai cela :

• Une requête pour sélectionné les tronçons (généralement les tronçons d'un autoroute ou d'un autre)
• Une requête pour sélectionner chacun des sens associés

Si je remonte quatre tronçons, j'ai donc 1+4*2 requêtes. 9 requêtes pour une page web, c'est trop. Alors il faut optimiser son code. Sous Hibernate (un ORM Java), on peut lui dire : quand tu charges un tronçon, tu charges systématiquement les sens associés. Mais on a pas cette possibilité sous Zend. Ce n'est pas un mal, car le paramétrage d'Hibernate, si il permet bien des choses, est un enfer. Et trouver un architecte vraiment compétent en Hibernate est difficile.

Sous Zend, voilà la solution que j'ai proposée : On continue pour les objets simples d'avoir un objet par table. Ce ne sont pas des objets métiers à mon sens, mais des objets persistants dans ma vision. Ensuite pour les cas complexes comme cité ci-dessus, je crée de nouveaux objets métiers. Et là, j'ajoute des méthodes DAO où je construis les requêtes à la mimine pour chaque interrogation. (En clair je construis une requête qui me remonte les tronçons de l'autoroute A31 et qui me remonte les segments associés (un vulgaire INNER JOIN en somme, rien de complexe).

Pour résumé, j'ai une classe objet pour chaque table métier. Généralement cela sert toujours (notamment pour les CRUD) Ensuite, pour des cas d'utilisations particuliers, je rajoute d'autres objet orienté métier et j'optimise les requêtes de sélection. Dans notre exemple Java cette modélisation a fait gagné un temps monstrueux pendant les heures de charge. Sous Zend, dans une application plus légère cette modélisation a fait gagner du temps. Je pense qu'il ne faut pas hésiter à avoir des tables modélisés de différentes façons.

[Yogui]

Oh, voici un beau retour d'expérience. Ce n'est pas tout à fait le sens de ma question mais c'est intéressant

En revanche, une question me vient : pourquoi ne pas faire des vues (CREATE VIEW) ? Si tu utilisais des vues dans tes modèles Db pour faire tes requêtes SELECT, est-ce que cela ne permettrait pas de résoudre très facilement le problème des tuples associés ?

[Alexandre T]

Pourquoi ne pas faire des vues (CREATE VIEW) ?

Cet exemple est sous Java-Hibernate. Nous n'avons pas utilisé les vues en raison d'un manque d'expértise en Hibernate. Mais si on applique ce modèle à Zend, oui une vue, ensuite mappée, est une bonne solution pour une couche de présentation en lecture seule.

Ce n'est pas tout à fait le sens de ma question mais c'est intéressant

Je relis ta question...

Oui alors mes contrôleurs sont vraiments très très simple personnellement. Ils ne contiennent que quelques lignes. Ils vérifient les variables transmises en paramètre, appele un singleton de mon ServiceFactory et lance une action.

Par contre, ma couche métier ne se sert pas de modèles formulaires. Mes objets de formulaires existent bien mais pour les formulaires de saisie (enfin du traditionnel en somme). Par contre je gère une couche que j'appelle valueobject, des objets métiers donc. Et je réalise en te lisant que ce serait une bonne idée. Bien que... si ils n'héritent pas de formulaires, ils peuvent toujours utiliser les chaînes de validation au niveau des Setters.

J'ai bien compris ta question ?

[Yogui]

Voilà, tu touches au point qui me pose question : pourquoi considère-t-on que la "couche métier" est constituée d'objets Db ? Pourquoi pas des objets Form par exemple (même si on le les affiche pas en HTML) ?

La question d'inclure des "modèles abstraits", ie. pas liés à une BDD ou à du HTML ou à des webservices, s'est posée plusieurs fois pour ZF. Je crois qu'il y a même eu des tentatives de composants, mais la team les refuse systématiquement pour la même raison que ce qui m'a poussé à lancer le débat ici : un objet métier est tellement lié à l'application qu'il n'est pas possible de généraliser.

Certaines applis utilisent majoritairement la BDD, d'autres majoritairement es services (ie. les mashups), d'autres encore presque exclusivement des formulaires (ie. pour le calcul).

Pourquoi, en ce cas, parle-t-on toujours des modèles comme si c'étaient toujours des objets Db ? Il me semble que c'est inexact. J'ai même la sensation que les objets Form sont mieux adaptés que les objets Db car ils ont déjà une chaîne de validation/filtres, ce que n'ont pas les objets Db de base de ZF. Quelle est ton expérience à ce niveau ?

[Alexandre T]

Alors dans ce cas, nous avons le même avis. Je ne considère pas les objets métiers comme des objets DB (pour moi c'est la couche persistance). Dans mes modélisations, ce sont comme des valueobject. Ils sont très très simple : un bean quoi. (Rappel en java un bean est un objet qui possède des propriétés protégées, et deux méthodes publiques get/set pour chaque propriété. Ensuite j'implémente des méthodes métiers (rechercher les parents, calculerTVA, activerCompte, etc... . Personnellement, j'implémente les règles de gestion de format, d'initialisation comme des validateurs dans mes formulaires en PHP. Et ensuite, je ne le vérifie pas dans les objets métiers.

Mais en en discutant avec toi, j'ai fait des tests. Mettre ces validateurs dans mes objets métiers et les faire hériter presque de formulaire. Et ce n'est pas convaincant de dériver d'objet de formulaires pour les objets métiers. Pourquoi ? Et bien je me retrouve à faire les tests de validation dès le setters. Et je fais le test trop souvent (ie quand j'extirpe l'objet de la couche de persistance, il est propre et quand je l'envoie à la couche métier, le retester est inutile)