Zend FR

si tu prend la partie administration
tu vas avoir par exemple des cas d'usage (sens UML)
qui vont être create prject, remove project, edit project, create resource, remove ressource, edit ressource, create task, remode task, edit task, affect task to ressouce, etc...

en supposant que tu parte sur un contrôleur d'administration ton contrôleur vas devoir implémenter des actions qui correspondent à ces cas d'usage.

on vois pourtant nettement apparaître trois notion que sont le projet la ressource, et la tache. et un acteur administrateur. chaque notion est relativement indépendante des autres sans pour autant l'être complètement. on ne peut pas dire que ma gestion de tache ou de ressource soit indépendante de la gestion de projet. mais en même temps elles relèvent chacun d'une certaine unité d'usage.

on a donc trois ensembles cohérents de cas d'usage qui sont regroupé dans un tout.
en faisant trois contrôleur pour ces trois cas on obtient une structuration de l'application plus claire et plus facile à maintenir. mais en même temps on perd dans la tas de contrôleurs de l'application l'ensemble administration. c'est là qu'intervient le module. le module vas permettre de regrouper l'ensemble de ses contrôleurs dans un tout homogène.

ce genre de réflexion sur l'usage de ton application doits t'amener à définir l'ensemble de tes contrôleurs et la façon de les regrouper. (cela facilite ensuite la définition des ACL) tu auras alors défini des module au sens appréciatif. et cela n'implique pas que le modèle de l'application soit lui aussi découpé en module ni même si cela était le cas suive le même découpage.
les modules (sens ZF) servent à définir les regroupements de l'usage de l'application.
les regroupements de modèles eux se font en fonction des notions métier (des éléments manipulés et non des manipulations)

nous en sommes donc là arrivé à la une architecture applicative issue de la spécification générale de l'application.

la phase de conception vas introduire d'autres éléments comme le fait que certains éléments de l'application existe aussi dans d'autre application et sont récurent. lorsqu'on rencontre ce genre de situation il bon de se poser la question: "dois-je en faire un module ?" en effet si on identifie ce genre de chose et qu'on le place dans un module cela permet de bien identifier dans l'application elle-même les éléments en question mais aussi de permettre la réutilisation du module dans une autre application.
souvent quand c'est le cas on retrouve un découpage au niveau du modèle qui est en phase avec le module et une indépendance du module avec le reste de l'application (le lien avec le reste de l'application ne se faisant qu'à travers le modèle)

si tu fais tes digrammes de cas d'usage de ton application tu vas avoir des cas fortement liés entre eux (on ne peut pas éditer une ressource qui n'existe pas créer supprimer éditer une ressource sont trois cas fortement liés) ils définissent tes contrôleur

puis tu vas avoir des cas plus faiblement lié
il n'y a pas de rapport entre supprimer une ressource et créer une tache pourtant affecter une tache à une ressource faite qu'il y a un lien entre les cas d'usage sur les ressources et ceux sur les tâches.
ces liaison faible vont faire apparaître des îlots de cas qui n'ont pas de relation directe entre eux.
ces îlots définissent des modules


de tous tes cas d'usage tu vas faire apparaître diverses notion sur les objets manipulés. la définition de ces notions en tant que telle sans regarder l'usage qu'on en fait vas faire là aussi apparaître des lient fort entre certaine notion la modélisation de ses notions vas te donner des classes métier et les liens entre elle des groupes cohérent et homogène. ces groupes peuvent alors être modéliser sous forme de package (sens UML)
dans ZF en général le plus simple pour les implémenter est de les regrouper dans des sous dossiers.

pour la doc regarde dans Zend_Contrôleur il y a un passage sur les modules.
A+JYT

ZF défini un cadre VC c'est à toi de choisir comment tu mets en place le M
imagine une appli de gestion d'une boutique
tu as des produits, un stock, des rayons,  des factures

un module d'administration va te permettre de créer ces éléments (sauf les factures) + les acteurs de la boutique et leur rôles.

que ce soit pour les produit, le stock, les rayons ce n'est pas dans le module admin que tu vas utiliser ses éléments il n'entre pas à proprement parler dans le métier de l'administrateur mais plutôt dans celui de la boutique. les produit vont par exemple être commandé et stocké par les gestionnaire de stock, ils vont être utilisés par le mershandiser qui vas organiser et les placer en rayon, puis il passeront dans la vente.

une fois vendu au travers de leur référence et facture dans la comptabilité

bref on voit nettement que le modèle lier au métier produit n'est dans le périmètre d'aucun des différents acteurs du processus de vente mais qu'il est transverse à l'application.

ce modèle à tout intérêt à être au niveau de l'application. 


le module admin va donc contenir des action lié au uses cases produit mais le modèle utilisé dans ces uses caes seront dans l'appli et non le module.

de même si tu crées un modèle pour la gestions de stock le mershandiser qui vient prendre des produit dedans le stock devra accéder au modèle en question (pour consommer du stock) mais il n'y a pas d raison de déplacer le modèle stock dans son module. il semble plus approprié de le mettre dans le module gestion de stock.

sur ce simple exemple tu peu donc voir apparaître un module admin avec des éléments de modèle user et rôle qui lui sont propre

des module gestion de stock et merchandising qui partagent un modèle alors que c'est l'un d'eux qui le porte (stock)
et un modèle qui n'est dans aucun des modules car partagé au niveau de l'application.


il va de soit que c'est une question de choix tu pourrais tout aussi choisir de mettre chaque modèle dans un module et de les partager comme pour le stock. ou au contraire de mettre tous les modèles dans l'application et donc dans aucun module.

ce que je voulais faire passer c'est qui ne faut pas s'imposer à priori de contrainte d'implémentation.
il faut au contraire éviter de réfléchir à l'implémentation et se concentrer sur les données du problème. c'est de l'analyse de celles ci que l'on tire l'organisation de l'application.

A+JYT

Dernière modification par sekaijin (26-07-2009 11:37:11)