Zend FR

@delprog : Mais donc est-ce vraiment utilisé pour mettre une méthode save en utilisant un quelconque Mapper ? car si j'ai bien compris en lisant sur internet il permet surtout de pouvoir contrôler l'accès aux méthodes.

Je suis entrain de regarder du coté de Doctrine en ce moment (tout en essayant de m'améliorer en anglais pour déchiffrer la doc ), et j'ai l'impression (si je ne me trompe pas) qu'il fait automatiquement le mapping donc plus besoin d'objets Mapper. On peut donc juste se contenter des patterns DAO et Service ?

Et en règle générale, si j'ai bien compris, c'est bien dans les DAO (en lisant tes divers post) qu'on peut utiliser Doctrine ainsi que les méthodes save... implémentées dans les modèles Entity.

J'aurais une autre question de logique métier si tu sais y répondre. Comment séparer d'un point de vue convention de nommage ou logique des objets servant uniquement à faire des actions comme par exemple un générateur de pdf utilisant des objets Entité comme Model_Article.

Par exemple : un objet Generateur(ArrayObject $articles) avec des méthodes toPdf ou toCsv etc..
et un objet Article().

C'est 2 m'ont l'air d'avoir des rôles différents. Tu me diras on peut mettre les méthodes toPdf et toCsv directement dans l'objet Article. Mais on peut imaginer que l'objet Generateur pêche plus large, et pas seulement des articles mes divers objets de mon application (seulement de mon appli car après ça s'intègrerait dans le dossier library je pense).

enfin voilà, qu'en on a pas beaucoup d'objet ça va mais arrivé à un certain stade tout me semble mélangé. Je pense mettre un espacedenom différents de l'un à l'autre mes lequels ?

Salut,

+1
La version 2 de Doctrine est très prometteuse (c'est un clone de Hibernate pour ceux qui ont pu y toucher), et il sera possible de vraiment séparer son métier de sa persistance. Aujourd'hui c'est difficilement possible puisque les entités sont générées par l'ORM. Là ce sera vraiment du mapping personnalisé sur nos propres objets.

citronbleu-v a écrit:

Et en règle générale, si j'ai bien compris, c'est bien dans les DAO (en lisant tes divers post) qu'on peut utiliser Doctrine ainsi que les méthodes save... implémentées dans les modèles Entity.

Si tu veux bien séparer ta persistance de ta logique, mais aussi t'assurer que ton appli. fonctionne même si tes données ne viennent pas d'un SGBDR tout devrait être dans une couche d'accès aux données (DAO ou autre Repository).
Ce que je fais maintenant c'est que je crée des interfaces de Repository qui appartiennent à ma couche métier et qui sont implémentées par ma couche infrastructure. De cette manière chaque objet métier est accompagné d'un contrat pour la récupération de ses données, après dans l'implémentation peu importe d'où ça vient
Et j'injecte évidemment les interfaces dans mes services, c'est tout l'intérêt.

Pour ta question, si les représentations PDF et CSV diffèrent vraiment selon les objets, j'implémenterais les méthodes dans l'objet lui même, en implémentant une interface.

Ou tu peux aussi avoir un générateur séparé propre à chaque objet. Je pense par exemple aux DTO qui ont chacun leurs propres assembleurs. Tes générateurs pourraient étendre un générateur abstrait qui implémente déjà les traitements communs à tous les générateurs en plus de définir des méthodes à implémenter dans les classes filles, toPdf() par ex. (contrat).

La solution est celle qui te convient le mieux


Un petit avertissement quand même, je parle de couches, mais attention encore de ne pas tomber dans le vice des couches pour faire des couches parce que c'est joli. Selon la dimension de l'appli ou la scalabilité ça peut être totalement inutile et obliger à accoucher du code et du code sans intérêt.

Par ex. je suis sur une grosse appli. en ce moment dont l'API pourrait être distribuée et où j'ai donc besoin de construire une API via des services qui doivent gérer les ACL, les filtres/validations etc. et je n'ai pas eu d'autre choix que d'implémenter des DTO avec leurs assembleurs et tout ce que ça ajoute comme objets, comme code et comme pertes de performances. Si je pouvais m'en passer je le ferais


A+ benjamin.

Dernière modification par Delprog (27-01-2010 10:53:03)