Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Zend_Db PHP Discussion :

Transactions et design pattern mapper


Sujet :

Zend_Db PHP

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 105
    Points : 57
    Points
    57
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    $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

  2. #2
    Membre expérimenté
    Avatar de 5h4rk
    Homme Profil pro
    CTO at TabMo
    Inscrit en
    février 2011
    Messages
    813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : CTO at TabMo
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2011
    Messages : 813
    Points : 1 373
    Points
    1 373
    Par défaut
    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

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 105
    Points : 57
    Points
    57
    Par défaut
    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.

  4. #4
    Membre expérimenté
    Avatar de 5h4rk
    Homme Profil pro
    CTO at TabMo
    Inscrit en
    février 2011
    Messages
    813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : CTO at TabMo
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2011
    Messages : 813
    Points : 1 373
    Points
    1 373
    Par défaut
    Citation Envoyé par boubil Voir le message
    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é.

  5. #5
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 105
    Points : 57
    Points
    57
    Par défaut
    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 ?

  6. #6
    Membre expérimenté
    Avatar de 5h4rk
    Homme Profil pro
    CTO at TabMo
    Inscrit en
    février 2011
    Messages
    813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : CTO at TabMo
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2011
    Messages : 813
    Points : 1 373
    Points
    1 373
    Par défaut
    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

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 105
    Points : 57
    Points
    57
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    $mapperpersonne->save($personne);
    $mapperadresse->save($adresse);
    Et la je ne vois pas bien comment je peux mettre une transaction autour de ça.

Discussions similaires

  1. Design Pattern "data mapper", quelques précisions
    Par comode dans le forum Langage
    Réponses: 5
    Dernier message: 23/07/2013, 17h20
  2. [ZF 1.11] Implémentation design pattern data mapper
    Par Kunai dans le forum MVC
    Réponses: 6
    Dernier message: 22/02/2012, 18h37
  3. Réponses: 4
    Dernier message: 24/02/2009, 13h06
  4. Les Designs Patterns Entreprise
    Par boulon dans le forum Design Patterns
    Réponses: 4
    Dernier message: 01/09/2004, 20h16
  5. [Design Patterns] Architecture 3 tiers
    Par HPJ dans le forum Design Patterns
    Réponses: 1
    Dernier message: 29/07/2003, 12h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo