Zend FR

Moimeme · 29-07-2009 14:35:12

Bonjour à tous,

Je me pose pas mal de questions concernant les objets métiers et leur interaction avec la BDD et le model.
Ou mettez-vous vos interfaces, ou sont vos objets métiers abstraction de plusieurs tables ... ?

Par exemple si j'ai un objet métier Ville il peut alors être un Zend_Row de ma table Ville (un code postal et un label). Pareil je peux avoir un objet métier basé sur un Zend _Row de ma table Passion(id passion et label passion).
En revanche si j'ai un objet métier user celui-ci est basé sur la table user(id user, nom user) mais il comporte un objet Ville et une collection d'objet Passions, comment faire cela de façon proprement avec des vrai objets métier, interfaces et ou les mettre ? dans le rep model ?....

Delprog · 29-07-2009 15:15:15

Salut,

De mon côté j'ai plusieurs choses, l'objet métier, le mapper, et la persistance.

Objet métier = Objet représentant une entité définie par ses propriétés.
Persistance = Table(s) (collection de rows) + row(s) (un éliment dans la collection, dans la table). Attention ça c'est pour une BDD classique, mais ce ne sont pas forcément des tables.
Mapper = Outil de transition entre le métier et la persistance.

Un objet métier ne correspond pas forcément à une table, il peut être construit à partir de plusieurs tables (jointures).

Une classe métier est donc constituée de setters et de getters. Le mapper est chargé d'instancier tous les éléments nécessaires de la persistance (Zend_Db_Table et Row) et de construire mon objet métier à travers les setters. Il est chargé dans l'autre sens d'effectuer les insert et les update là il faut (dépendances) à partir de mon objet métier.

Ce qu'on voit souvent dans les exemples depuis le dernier Quickstart ZF, ce sont des controlleurs qui créent des objets métiers et manipulent directement les mappers pour atteindre la persistance (Zend_Db = base de données).

De mon côté, j'ai en plus ajouté la notions de services. Pour faire simple, les controlleurs consomment les méthodes de services qui eux se chargent de la rencontre entre les objets métiers et la persistance.

Donc, mes controlleurs ne manipulent que des objets métiers et des services, jamais rien d'autre.

Exemple:

Je veux créer une news. Mon controlleur va créer l'objet métier de la news et va ensuite faire appel à la méthode addNews() du service NewsService qui attend en paramètre un objet métier "News".

Code:

$news = new Model_News();  // objet métier
$news->setTitle('Titre de la news'); // pourrait venir d'un formulaire
$news->setText('Texte de la news'); // pourrait venir d'un formulaire

$this->_newsService->addNews($news);

Le service NewsService va se charger de faire appel au mapper et de déclencher les traitements pour les insertions dans la base.

Mais la couche de services n'est pas obligatoire. Ca pourrait aussi bien être une façade, ou même rien du tout. Les controlleurs pourraient faire appel directement aux mappers.

Nous pourrions aussi bien décider que les mappers ne sont pas nécessaires et faire communiquer les controlleurs directement avec la persistance (avec Zend_Db). C'est d'ailleurs très fréquent. Mais attention, dans ce cas là, les controlleurs sont dépendants de la persistance. Si demain la techno change, une base SQL qui devient du XML par ex., et bien il faudra re-factoriser non seulement la couche de persistance (Zend_Db), mais aussi les controlleurs. C'est très contraignant.

Il existe donc plusieurs solutions pour éviter ça. Manipuler des objets métiers dans les controlleurs et faire appel à des objets chargés de communiquer avec la persistance. Ces objets peuvent être des mappers, une façade, des services, les deux (voir les trois), mais d'autres conceptions existent, c'est un peu comme on veut et en fonction du niveau de découplage recherché.

De mon côté j'ai pris parti pour les services (design pattern "Service Layer"). Ca me permet de découpler totalement mon front du back. Je peux très facilement changer mon front sans rien toucher dans le back et inversement.

Pour ce qui est de l'arborescence des dossiers, c'est un peu comme bon te semble. La meilleure solution n'existe pas.
Pour ma part, j'ai (ex. pour un objet):

Code:

models/
    User/
        Mapper.php
        Table.php
        Row.php
    User.php    <--- Objet métier
    
services/
    UserService.php

A+ benjamin.

Moimeme · 29-07-2009 15:41:59

Très intéressant ton approche, tu as un exemple de code d'un de tes services et du mapper, stp merci ?

Dernière modification par Moimeme (29-07-2009 16:08:10)

Delprog · 29-07-2009 16:09:53

Je n'ai pas d'exemple à te donner là comme ça. Mais par contre tu peux déjà voir comment j'ai implémenté la couche de services:

http://www.z-f.fr/forum/viewtopic.php?id=3666

A+ benjamin.

Moimeme · 29-07-2009 16:23:21

ok merci

Delprog · 29-07-2009 16:51:10

Attention par contre, je viens de voir que tu étais en ZF1.7 et l'implémentation que je propose est compatible uniquement ZF1.8 et supérieur.

A+

Moimeme · 29-07-2009 17:11:54

ok merci. Et tes values object tu les considère comme des objets metiers ?

Delprog · 29-07-2009 18:46:40

Qu'entend-tu par "values object" ?

Moimeme · 30-07-2009 09:29:17

Values Object ce sont des objet qui contiennent que des propriétés et aucune methode.
En gros c'est des conteneurs de données.

Delprog · 30-07-2009 15:26:50

Salut,

Si j'ai bien compris, ce que tu appelles "Value Object" se nomme en réalité "Data Transfert Object". Je n'utilise pas ce pattern. Il est beaucoup utilisé en JAVA.

Pour moi son intérêt n'existe que pour les transferts de données depuis des serveurs distants. Ces objets sont plus faciles à sérialiser et plus légers (puisque dépourvus de méthodes), et les requêtes sont donc plus rapides.

De mon côté, ce sont les mappers qui se chargent de convertir mes objets entre le métier et la persistance.

A+ benjamin.

Dernière modification par Delprog (30-07-2009 15:40:04)

aelyta1 · 11-08-2009 15:41:59

Pour rebondir sur ceci je me posais une question : est il possible d'utiliser des objets métier sans qu'ils correspondent à une table en base de données ?

Delprog · 12-08-2009 09:48:13

Salut,

C'est même très souvent le cas.

Par exemple tu gères des tags sur des articles d'un site.
Tu décides au départ d'avoir deux tables en BDD, une pour les articles, une spécifiquement pour les tags.

Ton objet métier lui, ne sera qu'une seule entité et possèdera une propriété qui contient ses propres tags. Il n'y aura pas un objet métier pour les articles et un pour les tags.

Au moment où tu vas vouloir récupérer ces informations depuis la bdd et construire ton objet métier (via des setters), ta couche DAO va requêter deux tables, et construire un seul objet métier qui te sera retourné.

Dans mon cas, c'est le service ArticleService (par ex.) qui proposera une méthode getArticles(). Cette méthode du service invoque le mapper "ArticleMapper" qui lui traduit ma demande pour la couche de persistance (Zend_Db) et va donc déclencher les requêtes nécessaires puis renvoyer une collection de rows. La méthode de mon service reçevra donc une collection de rows et peut construire mon objet métier puis le renvoyer au controlleur qui a invoqué la méthode du service.

Maintenant, pour X raisons je décide de mettre les tags dans la table articles et de me séparer de la table tags. Mon objet métier ne bouge pas d'un poil, mes controlleurs non plus du coup puisqu'ils ne manipulent que ça. Mon service non plus, c'est le mapper et la couche de persistance (Zend_Db) qui changent.

C'est tout l'intérêt (entre autre) de ces patterns.

A+ benjamin.

aelyta1 · 13-08-2009 08:28:16

Merci pour tes explications, je vais tester dans mon projet ce que cela peut donner

slaughter · 13-08-2009 11:06:52

Au sujet du "Value Object", vous parlez bien de l'objet métier qui contient tout les getters et setters ?

J'ai une petite question pratique, je travaille actuellement sous Eclipse PDT et je cherche un moyen simple de générer tous ces getters et setters automatiquement selon les champs définis dans la classe. Il est possible de le faire en JAVA mais je ne trouve pas la même fonction dans Eclipse pour PHP. Avez vous une solution ?

slaughter · 14-08-2009 00:26:27

pour ceux que ça intéresse, voici le template Eclipse que j'ai fait :

Code:

public function set${method}($$${field}) {
    $$this->_${field} = $$${field};
}

public function get${method}() {
    return $$this->_${field};
}

Il n'y a pas de case à cocher selon les champs de la classe pour le génération de getters et setters comme le fait eclipse en java mais j'ai pas réussi à faire mieux.

Dernière modification par slaughter (14-08-2009 00:40:06)

Intiilapa · 14-08-2009 06:55:15

Il manque le return $this; dans le setter pour l'interface fluide

keilnoth · 14-08-2009 10:37:17

J'utilise un peu le même principe que Delprog sans le Mapper. Mon Mapper est en fait mon objet métier, mon modèle. Mon modèle lie mon contrôleur à ma base de données et ma base de données à ma vue.

Donc en gros, après la validation d'un formulaire, je fais ça :

Code:

public function editAction() {
    ...

    // plus aucun traitement dans le contrôleur
    // toute l'intelligence est dans le modèle, ce qui le rend transportable
    Model_User::edit($form->getValues()) ;

    ...
}

Structure de fichiers :

Code:

Model/
    User/
        Address/  <--- sous objet métier reprenant la même structure que l'objet parent
            Db/
                Table.php
                Row.php
        Form/      <--- formulaires Zend_Form lié à l'objet
            Create.php
            Edit.php
        Db/
            Table.php
            Row.php
        Address.php   <-- sous-objet métier
    User.php    <--- Objet métier
    
controllers/
    UserController.php

Voilà une autre approche. A noter que j'utilise une infrastructure modulaire. Mes contrôleurs sont dans un module que je peux également transporter de projet en projet.

Delprog · 14-08-2009 11:05:07

Salut,

En fait ce qui me dérange dans cette approche c'est que tu envoies directement $form->getValues(), donc tu dépend de la construction de ton formulaire.

Si par contre tu passes par un objet métier, c'est à dire création de l'objet + setters, et que tu passes cette objet métier, tu te détaches totalement de ton système.

Si demain tu n'utilises plus Zend_Form, ou plus des formulaires, ou que tu changes les attributs de tes champs ou je ne sais quoi, tu seras emmerdé je pense.

Après attention, il ne faut pas faire une conception sur-dimensionnée par rapport à la portée du projet concerné. Mais pour moi ça reste valable quand même.

A+ benjamin.

keilnoth · 14-08-2009 11:51:44

Je comprends pas trop ta remarque. Je ne reçois qu'un tableau de données, peu importe sa provenance. L'appel $form->getValues() est dans le contrôleur qui affiche ce même formulaire, et la méthode renvoit un tableau, donc il n'y a pas de dépendance. Je peux très bien passer un tableau de données simple provenant de n'importe où.

A un moment donné, les données que tu mets à jour doivent bien venir d'un formulaire ou d'un tableau ou d'un input quelconque. Bien entendu, l'input doit correspondre un "minimum" à l'objet qu'il désire traiter.

En fait, mon objet "Table" sait quels champs il peut mettre à jour et il va parcourir le tableau de données qu'il reçoit pour récupérer que les champs dont il a besoin. C'est lui qui doit savoir ça afin de répercuter les modifications de la base de données.

Je peux ainsi ajouter un champ dans ma table DB et un champ dans mon formulaire et je n'aurai aucune autre modification à faire.

Et si par exemple je retire un champ de mon tableau, ce champ ne sera simplement pas mis à jour. Ca n'aura aucune autre incidence. Si j'ai un champ en trop dans mon tableau, il sera oublié.

Si en plus on utilise l'objet "Row" dans le modèle alors il n'y a encore moins besoin de couche supplémentaire. L'objet "Row" supporte parfaitement la définition de ses champs en lui passant un tableau ou via des setters.

A ce moment là, mon modèle peut simplement faire :

Code:

$table = new Model_User_Db_Table() ;
$row = $table->createRow() ;
$row->firstname = 'mon prénom' ;
$row->lastname = 'mon nom' ;
$row->save() ;

// mais je préfère
$row->fromArray($datas) ;
$row->save() ;

Si en plus je peux paramétrer l'objet "Model_User_Db_Table" dans le modèle alors je n'ai plus de dépendance du tout.

EDIT :

Hop, pour démontrer ce que je dis, j'édite un utilisateur via un fichier de données uploadé :

Code:

public function importAction() {
    ...

    $user = file_get_contents($uploaded_file) ;
    Model_User::edit(unserialize($user)) ;

    ...
}

C'est tout... Je n'ai pas modifié la méthode edit() de mon modèle.

Dernière modification par keilnoth (14-08-2009 11:56:46)

Zend FR

#1 29-07-2009 14:35:12

[ZF 1.7]Objets métiers et model

#2 29-07-2009 15:15:15

Re: [ZF 1.7]Objets métiers et model

Code:

Code:

#3 29-07-2009 15:41:59

Re: [ZF 1.7]Objets métiers et model

#4 29-07-2009 16:09:53

Re: [ZF 1.7]Objets métiers et model

#5 29-07-2009 16:23:21

Re: [ZF 1.7]Objets métiers et model

#6 29-07-2009 16:51:10

Re: [ZF 1.7]Objets métiers et model

#7 29-07-2009 17:11:54

Re: [ZF 1.7]Objets métiers et model

#8 29-07-2009 18:46:40

Re: [ZF 1.7]Objets métiers et model

#9 30-07-2009 09:29:17

Re: [ZF 1.7]Objets métiers et model

#10 30-07-2009 15:26:50

Re: [ZF 1.7]Objets métiers et model

#11 11-08-2009 15:41:59

Re: [ZF 1.7]Objets métiers et model

#12 12-08-2009 09:48:13

Re: [ZF 1.7]Objets métiers et model

#13 13-08-2009 08:28:16

Re: [ZF 1.7]Objets métiers et model

#14 13-08-2009 11:06:52

Re: [ZF 1.7]Objets métiers et model

#15 14-08-2009 00:26:27

Re: [ZF 1.7]Objets métiers et model

Code:

#16 14-08-2009 06:55:15

Re: [ZF 1.7]Objets métiers et model

#17 14-08-2009 10:37:17

Re: [ZF 1.7]Objets métiers et model

Code:

Code:

#18 14-08-2009 11:05:07

Re: [ZF 1.7]Objets métiers et model

#19 14-08-2009 11:51:44

Re: [ZF 1.7]Objets métiers et model

Code:

Code:

Pied de page des forums