Zend FR

mikaelkael · 21-02-2009 11:44:48

Hello,

sekaijin a écrit:
dans ce cas là IE ce n'est pas l'objet form qui fait le rendu mais l'a vue c'est un objet qui gère les donnée d'un formulaire c'est donc un objet de contrôle

un objet métier défini un concept pas l'usage qui en est fait je comprends que associer le formulaire au modèle facilite le travail mais ça resserre les liens et justement le but de MVC c'est de les découpler.

Je n'ai pas souvenir de cas précédents qui m'ont posé des soucis. Si cela m'arrive, j'essaierais de me rappeler cet échange .

sekaijin a écrit:
dans ce cas là je mettrais moi deux objet un métier et un de contrôle (un plugin de contrôler)

J'avais pas pensé à cette solution qui me plait mieux que l'extension de Zend_Controller_Action.

Merci en tout cas pour tes éclaircissements

A+

ALkyD · 26-02-2009 18:34:15

sekaijin : dans ce cas-là, le gros du code d'une application MVC se trouve principalement dans les contrôleurs ? Que possède-tu dans tes classes de modèles, exceptées les méthodes et propriétés qui étendent celles de Zend_Db_Table_Abstract ? Je pose cette question car il est possible de récupérer le SQL directement dans le contrôleur, en faisant un

Code:

$table = new Ma_Table();
$rowset = $table->fetchAll();
...

Merci

Delprog · 26-02-2009 19:33:24

Salut,

Ce n'est pas à mon avis une bonne pratique de toute manière. En imaginant que demain la couche métier pourrait techniquement être gérée de mille manières différentes. L'idéal est de manipuler des objets avec des méthodes assez génériques et de manipuler les méthodes propres à la classe où au système d'organisation des données dans les modèles.

Le mieux est de détacher le plus possible les controlleurs et les rendre indépendants de la techno utilisée pour l'organisation des données. D'où la notion de façade citée plus haut dans le thread.

MVC est relativement simple dans la théorie. Le modèle manipule des données directement, le controlleur invoque le modèle et formate le résultat obtenu pour la vue qui elle l'affiche.

En respectant MVC on aurait donc quelquechose du genre :

Code:

$table = new Ma_Table();
$resultat = $table->getQuelqueChose();
.....

Ici s'arrête MVC.

Après pour moi ce n'est pas suffisant et ça ne détache pas suffisamment la persistance de la couche métier.
Pour qu'un projet soit facile à maintenir, il faut que le dev métier n'impacte pas directement l'application et ne re-demande pas systématiquement une re-factorisation du code dans les controlleurs.

Mais la plupart des dev mettent plus ou moins "proprement" et instinctivement une couche supplémentaire pour éviter ça. Il faut surtout être logique et conserver la même optique de conception de bout en bout.

Je sais que tu attendais une réponse de sekaijin mais je me permet d'apporter ma petite remarque

A+ benjamin.

sekaijin · 26-02-2009 21:18:31

ALkyD a écrit:
sekaijin : dans ce cas-là, le gros du code d'une application MVC se trouve principalement dans les contrôleurs ? Que possède-tu dans tes classes de modèles, exceptées les méthodes et propriétés qui étendent celles de Zend_Db_Table_Abstract ? Je pose cette question car il est possible de récupérer le SQL directement dans le contrôleur, en faisant un
Code:
$table = new Ma_Table();
$rowset = $table->fetchAll();
...
Merci

Non
Prenons un exemple à la fois simple mais pas basique
je fais une application dans laquelle il va y avoir une facturation.
je vais donc manipuler des factures
un facture est un objet qui a un identifiant unique (obligation légale)
elle a une référence à un client
une date de facturation
une date de payement
etc.
une facture est aussi constituée de lignes de facturations
chaque ligne référence un article possède une quantité référence des remise un prix total hors taxe et un prix TTC et un total de taxe

etc...
si je prends l'objet facture il doit me fournir un prix ttc un prix ht et un total de taxe
l'objet facture va donc porter la(es) méthode(s) de calcul du montant de la facture.
cela s'appelle une règle métier c'est donc l'objet métier facture qui la porte
notez que je n'ai absolument pas dit ce que mon application allait faire de cette facture. ce qu'en fera le contrôleur n'est pas le problème du modèle.
continuons
la ligne de facturation doit elle aussi me permettre de renseigner pour la ligne les valeur ttc ht et tc les taxes pouvant varier d'une ligne à l'autre en fonction du produit mais étant aussi fonction des remises
la encore les méthodes de calcul sont propre aux ligne de facturation.
on pourrait continuer avec les articles, les remises, et les clients (les bons clients pourrait obtenir des remise globales supplémentaires) mais je doit pouvoir connaitre les impayés de me clients, qui se calcule sur une règle portée par le client. ainsi les règles de gestions de ma facturation sont toutes portées par mon modèle et celui-ci doit me garantir une bonne facturation.

J'ai donc là défini mon modèle. On peut remarquer qu'il n'a pas été question de Contrôleur ni de vue on a Modélisé l'activité de facturation et on va pouvoir l'utiliser dans toutes les applications de l'entreprise qui en aura besoin.

maintenant je fais l'application qui gère l'atteler Auto de ma concession et dans cette application il y a une partie facturation pour les pièces et les actes. je vais devoir fournir un moyen de créer ma facture. je vais donc utiliser mon modèle pour cela. Mais ce n'est pas l'atelier qui gère le payement ni l'édition des facture il n'utilisera donc pas tous ce qui est défini dedans.
puis je fais l'application du service comptable. la encore je vais utiliser le même modèle et utiliser d'autres partie de celui-ci. donc les méthodes de calcul d'édition et de recouvrement.

on vois donc que le travail des contrôleur va être fondamentalement différent d'une application à l'autre bien qu'elle se basent sur le même modèle de facturation.

on a défini le modèle on a vu comment l'utiliser mais on n'a pas dit comment on allait conserver l'information.
on va donc choisir un support fichier XML base objet base relationnelle fichier plat annuaire etc.
une fois le choix établit il faut définir sous quelle forme un garde les données. pour une base il faut définir les tables vues contraintes relations etc. cette activité dans la conception d'une base s'appelle la modélisation. il ne faut pas confondre la modélisation des donnée et la conception du modèle métier.
plutôt que le terme anglais de model pour la partie métier certain parlent simplement de métier (le métier de l'application)
bref une fois la conception de la base fait il faut définir comment on va faire entrer les objet métier dans la base. cette étape s'appelle la persistance. c'est là qu'un va trouver les classes dérivées de Zend_DB_Table_*
on va par exemple créer un Concession_Facture_Table et Concession_Facture_Table_Row le rôle de ses classe sera de de s'assurer qu'on puisse prendre un objet métier facture et le mettre dans la base et vice versa.

il va se poser alors une petite question quand lire et enregistrer. il revient aux objets métier de définir quand il est opportun d'assurer la persistance. le contrôleur n'est pas censé en être informé. mais dans la réalité c'est beaucoup moins simple. et le plus souvant l'objet métier fournit au contrôleur une (des) méthode(s) qui permette de déclencher la persistance de façon explicite.

Le contrôleur n'as donc jamais à faire à la base de donnée il ne connait que le métier et c'est à travers lui qu'il accède à la base. si on venait à changer de méthode de persistance (par exemple appel de service soap)on ne devrait pas avoir à changer un seul point virgule dans les contrôleurs.

il faut aussi être pragmatique et si je fais une application qui ne fait que lire et écrire des données une telle conception est peut-être sur dimensionné. il faut souvent trouver un juste milieu pour minimiser les cout de dev et d'exploitation.

Je conseille tout de même de faire au moins une fois un petit exemple complet qui implémente toutes les couche de façon stricte. c'est à dire aucun traitement dans la vue, aucune mise en forme dans le contrôleur, aucun accès au donné dans le contrôleur. aucun calcul métier dans le contrôleur aucun accès à la base dans le métier, aucune mise en forme dans le métier, aucune mise en forme dans la persistance, aucun calcul dans la persistance.

On voit vite les difficultés de s'y tenir mais aussi les avantages qu'on peut en tirer.

pour finir il est courant et je le fais très souvent (tout le temps) de placer un objet unique entre le métier et le contrôleur. c'est objet ayant pour but de cacher au contrôleur la complexité du modèle. ce design pattern s'appelle une façade.

A+JYT

Dernière modification par sekaijin (26-02-2009 21:24:51)

nORKy · 26-02-2009 21:29:34

Qui c'est qui a la plus grosse ???

Moi, j'ai des classes pour chaque formulaire et qui prenne en paramètres mes modèles ou rien !
Rien pour un formulaire vide, un objet pour un formulaire pré-rempli.
Dans mon controller, ca se résume à new My_Form_Account_Edit($user);

J'utilise Doctrine comme ORM.
Mon formulaire est capable donc de trouvé les identifiants unique et de les intégrés en tant que champs hidden.
Le reste, n'est qu'un jeux d'enfant : form->populate($user->toArray());
Pour les données un peu plus complexe, je code des accesseurs dans mon modèle

Je fais ce que je veux... avec mes cheveux !

Je suis contre les formulaires dans les modèles et aussi contre les redirect à tous bout de champs !

De plus, je code actuellement un routeur qui va encore plus me simplifier la vie à la manière du routeur "propelRoute" de symfony

Dernière modification par nORKy (26-02-2009 21:30:52)

ALkyD · 27-02-2009 10:18:59

Merci sekaijin pour ta réponse. Ca m'a l'air un poil compliqué mais c'est beaucoup plus clair

Harry · 01-04-2009 11:45:30

Bonjour à tous et merci aux contributeurs !!

Nouveau sur le forum (c'est même mon premier message) je débute avec le ZF et me pose une question que j'ai déjà vue (http://www.z-f.fr/forum/viewtopic.php?id=905) quant à l'emplacement des objets métiers dans l'application.

Je relance donc ce post.

sekaijin a écrit:
sekaijin :
...
bref une fois la conception de la base fait il faut définir comment on va faire entrer les objet métier dans la base. cette étape s'appelle la persistance. c'est là qu'un va trouver les classes dérivées de Zend_DB_Table_*
on va par exemple créer un Concession_Facture_Table et Concession_Facture_Table_Row le rôle de ses classe sera de de s'assurer qu'on puisse prendre un objet métier facture et le mettre dans la base et vice versa.
...

Sekaijin propose donc de distinguer objets métiers et classes de persistances (Zend_Db), ce que j'ai personnellement fait car en effet certains objets métiers ne sont pas destinés à atterrir en base.

Je me demande juste où à votre avis ces objets métiers devraient se trouver :
Exemple pour un objet métier Client :
dans le dossier model, feriez-vous figurer "en vrac" et côtes-àcôtes les objets métiers avec les objets de persistance (Zend_Db) ? :
Client.php (objet métier)
ClientTable.php (objet Zend_Db_Table)
ClientRow.php (objet Zend_Db_Row)

Il s'agit probablement d'une question triviale mais j'envisage de refondre une application en utilisant une facade d'accès au métier (Sekaijin m'inspire beaucoup, mais il faut pouvoir suivre... he he pas toujours facile ) et je voudrais repartir d'un bon pied...

Merci d'avance !

Harry

Dernière modification par Harry (01-04-2009 16:32:39)

Harry · 02-04-2009 14:36:38

Pas de réponse ?
Vous m'inquiétez... S'agirait-il d'une question réellement stupide ??

sekaijin · 02-04-2009 15:14:55

ben moi j'ai pas répondu car je pense que tu connais ma réponse

Harry · 02-04-2009 16:54:06

Bon ben j'imagine que ça veut dire que oui... question stupide...
Il est vrai que ça porte sur un point de détail probablement sans grand intérêt mais j'aurais aimé en être sûr.

sekaijin · 02-04-2009 17:54:55

si
ça a un intérêt

séparer l'objet métier de la persistance de celui-ci permet de découpler les problématiques et de rendre l'application plus souple et maintenable
si mon appli ne parvient pas à enregistrer c'est de la persistance si elle ne parvient pas à faire un traitement c'est du métier

cela permet aussi d'évoluer plus facilement un objet métier stocké en base de donnée qui migre vers un annuaire LDAP par exemple tu ne modifie que la percistance tu as de nouveau traitement tu ne modifie que le métier

A+JYT

Harry · 02-04-2009 18:44:36

OK, je vois pour la séparation métier/persistance.
Mais quid de l'emplacement des objets métiers ? (ça pour le coup c'est plus de l'ordre du détail)
Pour ce qui me concerne j'ai fait un dossier metier dans le dossier models... et je me demande si ça ne va pas à l'encontre de la logique d'organisation des fichiers sous ZF.
J'ai donc :
/application/models/metier/Client.php
/application/models/ClientTable.php
/application/models/ClientRow.php
Merci pour la réponse.
++ Harry

Delprog · 03-04-2009 14:17:59

Bonjour,

Je ne pense pas que ça aille à l'encontre d'une quelconque logique, au contraire

De mon côté j'ai une arbo du type:

Code:

application/
      Controllers/
      Models/
            Bank/
                  Row.php
                  Table.php
            Client/
                  Row.php
                  Table.php
            etc.
            Front/
                  AccountManagement.php
                  Auth.php
                  Client.php
                  GeneralData.php                  
                  etc.             
      Views/
      Modules/
            MonModule/
                  Controllers/
                  Models/
                  Views/
            MonModule2/
            etc.

C'est un choix que j'ai fait, peut-être pas le meilleur, pour l'instant je ne suis pas embêté.

La seule problématique pour moi est de conserver les conventions de nommages (Pear/ZF), et de conserver le bon fonctionnement du Zend_Loader quelque soit la ressources.

Pour le reste, ce sont des choix personnels, qui parfois changent sur un déclic pratique

A+ benjamin.

Dernière modification par Delprog (03-04-2009 14:18:27)

Harry · 03-04-2009 14:59:35

Bonjour Benjamin et merci pour ta réponse.

Une petite précision pour être sûr :
- ton dossier application/models/front/ contient donc les objets métiers "de haut niveau"
- les dossiers application/models/bank ou application/models/client contiennent les objets de persistance Table ou Row auxquels les objets métiers de plus haut niveau font appel.

C'est bien ça ?

++ Harry

nORKy · 03-04-2009 19:42:09

Perso, je trouve que vous allez trop loin. Chacun l'arborescence qui lui convient me semble être la bonne solution.
Perso, je n'utilise pas Zend_Db* mais doctrine, donc peût que rien qu'a cause de ça, je fais les choses différement.

Code:

app/
    config/
    db/
         models/
             Group.php
             GroupTable.php
             User.php
             UserTable.php
             ...
         schema/
             .. (voir doctrine)
   Modules/
        ... (schema classic)
   Layouts/
       front.phtml
       back.phtml
   Lib/
     ..

Harry · 03-04-2009 20:29:49

Tu as surement raison nORKy, mais pour moi qui débute c'est rassurant d'avoir votre avis même si la question de l'emplacement était certainement un point de détail.

Par ailleurs, la distinction métier/persistance avait été très clairement expliquée par Sekaijin (http://www.z-f.fr/forum/viewtopic.php?id=1908) mais je l'ai vu après. Le dernier message du topic est particulièrement limpide, je me permets de citer : (merci Sekaijin)

"si ton modèle est très riche en traitement et n'a pas ou que peu de persistance alors tu peux faire une ou plusieurs classe pour ton modèle qui appelleront directement les classes Zend pour la persistance.

si ton modèle a beaucoup de traitement et de persistance alors le mieux est de définir des classes métier portant les traitement du modèle qui appelle des des classes de persistance dérivant des classes Zend.

si le modèle est pauvre en traitement mais lourd en persistance tu peux faire porter les traitements au classe table et row dérivées de celle de Zend"

A+ Harry

Zend FR

#26 21-02-2009 11:44:48

Re: MVC, requêtes sql dans le contrôler?

sekaijin a écrit:

sekaijin a écrit:

#27 26-02-2009 18:34:15

Re: MVC, requêtes sql dans le contrôler?

Code:

#28 26-02-2009 19:33:24

Re: MVC, requêtes sql dans le contrôler?

Code:

#29 26-02-2009 21:18:31

Re: MVC, requêtes sql dans le contrôler?

ALkyD a écrit:

Code:

#30 26-02-2009 21:29:34

Re: MVC, requêtes sql dans le contrôler?

#31 27-02-2009 10:18:59

Re: MVC, requêtes sql dans le contrôler?

#32 01-04-2009 11:45:30

Re: MVC, requêtes sql dans le contrôler?

sekaijin a écrit:

#33 02-04-2009 14:36:38

Re: MVC, requêtes sql dans le contrôler?

#34 02-04-2009 15:14:55

Re: MVC, requêtes sql dans le contrôler?

#35 02-04-2009 16:54:06

Re: MVC, requêtes sql dans le contrôler?

#36 02-04-2009 17:54:55

Re: MVC, requêtes sql dans le contrôler?

#37 02-04-2009 18:44:36

Re: MVC, requêtes sql dans le contrôler?

#38 03-04-2009 14:17:59

Re: MVC, requêtes sql dans le contrôler?

Code:

#39 03-04-2009 14:59:35

Re: MVC, requêtes sql dans le contrôler?

#40 03-04-2009 19:42:09

Re: MVC, requêtes sql dans le contrôler?

Code:

#41 03-04-2009 20:29:49

Re: MVC, requêtes sql dans le contrôler?

Pied de page des forums