Transactions et design pattern mapper

Bonjour


J'ai développé une applications ous zend à partir de quickstart (http://framework.zend.com/manual/fr/...ate-model.html)


En particulier j'ai utilisé le design pattern Mapper comme dans l'exemple.


Puis-je faire des transactions qui impliquement plusieurs mapper différents ? Comment dois-je m'y prendre ?

Ou dois-je mettre mon code pour être "propre" (ie pas dans le controller je suppose)

Actuellement dans une de mes actions, j'ai un formulaire qui met permet d'alimenter différents objets, et je voudrais que la sauvegarde des deux objects se fasse au sein d'une transaction.

Code:

---

1 2 3 4 5 6 7 8 9 10

$objetA = new Application_Model_ObjectA ($form->getValues()); $mapperA = new Application_ModelObejctAmapper($objectA);   $objetB = new Application_Model_ObjectB ($form->getValues()); $mapperB = new Application_ModelObejctAmapper($objectB);   $mapperA->save(); $mapperB->save();

---

Comment est ce que j'encapsule les 2 ->save dans une transactions; et où dois-je le faire (je n'aime pas mettre des appels base de donnée directement dans les controller je trouve que ce n'est pas leur rôle (bien que de nombreux exemples et tuto le fasse).

Par ailleurs, quand j'écris

Code:

---

$objetA = new Application_Model_ObjectA ($form->getValues());

---

est ce que je peux me contenter des eventuels validateurs et filtres présents dans le formulaire pour me garantir contre l'injection de code/... ou est ce que je dois mettre un filtre spécifique sur le setter ?


Merci d'avance

Bonjour,
Tout d'abord tu n'aurais pas du suivre entièrement le quickstart pour les DataMapper.

D'ailleurs, je trouve cela dommage que dans ce quickstart, l'exemple montre la création de plusieurs classe pour manipuler les objets alors que Zend le permet sans création de classe particulière.

Regarde du côté des Row si tu as le temps de revoir ton application.

Pour tout ce qui est transaction, tu peux faire tout ce que tu veux mais c'est un système à créer car il ne me semble pas avoir vu cela sur ZF

Je ne vois pas ce que tu reproches au pattern mapper.
Je me suis fait des classes génériques pour mes fichiers de models (avec la mécanique des _getter et _setter, plus des methodes de type toArray, toCSV,... et et pour les mapper qui font toutes les fonctions de base, et ensuite dans les classes modèle et dans les mappers je n'ai implémenté que les choses spécifiques. Je trouve ça plutôt très propre.

Avant j'avais fait bcp de java et on faisait quelque chose de similaire.

Citation:

---

Envoyé par boubil

Je ne vois pas ce que tu reproches au pattern mapper.
Je me suis fait des classes génériques pour mes fichiers de models (avec la mécanique des _getter et _setter, plus des methodes de type toArray, toCSV,... et et pour les mapper qui font toutes les fonctions de base, et ensuite dans les classes modèle et dans les mappers je n'ai implémenté que les choses spécifiques. Je trouve ça plutôt très propre.

Avant j'avais fait bcp de java et on faisait quelque chose de similaire.

---

Tout ce que tu as fait est existant dans les Row, du coup tu as refait quelque chose d'existant. Et tu as besoin de au moins 2 classes en plus par entité.

Oui et non, par ce que les row sont des objets standards, or dans mon appli j'apprécie d'avoir des objets typés (un client n'est pas un message, qui n'est pas une adresse,...

Du coup, juste pour te donner un exemple ma classe adresse a des getter/setter pour chaque champs de l'adresse plus un getter pour récupérer l'adresse complete (3 champs d'adresse + Cp + ville).
Et de plus toutes mes classes métiers heritent d'une class modele qui implemente des fonctions de base dont j'ai souvent besoin.

Je ne peux pas faire ca si j'en reste juste au niveau des rows non ?

Là ce ne sont pas de row qu'il s'agit, ni même de mapper mais de modèle indépendant de la base de données.

En gros, tu peux avoir 3 types de modele :
- Zend_Db_Table : Interaction avec la base de données retournant des rowset (plusieurs row)
- Zend_Db_Table_Row : retourn un seul row (une seule ligne de la BDD)
- Model : modèles sans interactions de base avec la BDD

Oui biensur, je suis d'accord avec toi.

J'ai mes objets métier (model) qui étendent d'ailleurs une class Model qui fait la colle pour trouver les getter/setter), ... et qui sont totalement indépendants de la base de donnée.


J'ai pour chaque objet métier un mapper qui fait la colle entre la base de donnée (les objets Row) et l'objet métier.
Chaque mapper étend une class abstraite qui contient une bonne partie de la mécanique d'accès a la base et les méthodes les plus standards (find, delete, fetch all. Toutes ces méthodes retourne l'objet métier qui va bien grâce a une fonction rowToObjet qui est implémentée dans chaque mapper.
Finalement chaque mapper n'implémente que les quelques méthodes spécifiques (ex save / update / ...).

Du coup tout l'accès a la base se fait a haut niveau dans les controller

Code:

---

1 2	$mapperpersonne->save($personne); $mapperadresse->save($adresse);

---

Et la je ne vois pas bien comment je peux mettre une transaction autour de ça.