Discussion :

[Guldil]

Bonjour,

Je suis actuellement différents tutoriels et le thread sur les fonctions générales rejoint en partie mes interrogations.
Souvent dans les tutoriels, on a affaire à des cas très (trop?) simples qui se limite à afficher / créer de simple enregistrements dans une base.

Imaginions par exemple que je veuille des objets persistants ou un des champs doit être unique ? Exemple on ne va pas créer un produit avec le même code barre EAN13. Mais ou met on cette règle ? est ce que Doctrine sait le faire ? Est ce dans le contrôleur ? Est ce dans la partie Entity ?

Autre cas, imaginions qu'on ait finalement des objets assez complexes, par exemple la réservation de terrain de sport avec des créneaux horaires de 30min. Je m'imagine bien faire un objet Terrain et a coté Planning avec pour un terrain le début / fin de la réservation.

Ou va t-on mettre tout la logique qui permet de savoir qu'un certain terrain est disponible, ou va t-on mettre la fonction qui construit visuellement un planning / calendrier ? Je ne pense que pas que ca soit une Entity non ? mais bien un objet métier qui utilise des Entity. Enfin c'est pour l'instant comme cela que je le vois...

Merci !

Guldil

[ibasaw]

Pour le champ unique tu peu l'indiquer dans l'entity

Pour ton 2 cas, je dirait que toute la logique doit être dans le controller.

A plus.

[bilbot]

Il faut créer des repository qui seront associés à tes entity, ca evite de mettre tout dans le controler et réduire la lisibilité du code. Voila un exemple :
Dans ton bundle tu crée un dossier repository dans lequel tu vas créer des fichier avec le nom : monEntityRepository.php

dans resource/config/services.yml tu vas venir configuer ce repository. Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
  ingredient_repository:
    factory_service: doctrine.orm.default_entity_manager
    factory_method: getRepository
    class: Menu\RecetteBundle\Repository\IngredientRepository
    arguments:
             - Menu\RecetteBundle\Entity\Ingredient

voici le fichier Ingredient repository :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
<?php
 
namespace Menu\RecetteBundle\Repository;
 
use Doctrine\ORM\EntityRepository;
 
class IngredientRepository extends EntityRepository {
//la tu viens mettre tes methodes metier ex :
  public function deleteById($id) {
    $query = $this->createQueryBuilder('i')
            ->delete()
            ->where('i.id = :id')
            ->setParameter('id', $id)
            ->getQuery();
 
    return $query->execute();
  }
 
}

Dans ton controler, il faut rajouter le repo dans les includes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
//repository
use Menu\RecetteBundle\Repository\IngredientRepository;

et un exemple d'appel dans le controler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$query = $this->get('ingredient_repository')->deleteById($id);

[pc.bertineau]

Des objets Repository vont te servir à placer des traitements sur ta couche de persistance (BDD) qui seront trop complexes pour laisser l'EntityManager de base le faire lui-même.

Pour le code Métier (hors accès BDD), les Services sont la manière la plus indiquée, tu peux jeter un oeil ici : http://www.developpez.net/forums/d11...2/#post6372337

[Guldil]

Merci Bilbot pour cette exemple, j'avoue que cette approche me plait bien !

Pc.bertinaut, n'est ce pas dans ce cas présent très lourd ?

Je sais qu'on doit respecter une certaine norme mais dans mon cas je trouve ca terriblement lourd à coder en plus, c'est tres verbeux pour quelque chose d'assez simple !

Surtout que généralement ce que justement je veux mettre en plus c'est la complexité métier donc souvent sa spécificité = peu de ré-utilisabilité possible...

[pc.bertineau]

Un Service n'est pas plus lourd à coder qu'un Repository...

Après c'est à toi de voir si tu veux séparer le code d'accès à tes données (côté Repository) et le code Métier (côté Service). Pour ton exemple de gestion de planning, je séparerais ces 2 logiques :

Le service utilise le Repository pour :
- Déterminer si un créneau est libre,
- Renvoyer le planning sur une période donnée,
- Renvoyer les créneaux réservés par tel utilisateur.

Et le service s'occuperait lui-même de faire les actions qui écrivent en BDD :
- Réserver un créneau,
- Détruire une réservation,
- ....

Dans la logique, le Repository te sert à accéder à tes données. On définira un Repository spécifique lorsque celui de base de Doctrine sera trop léger pour sortir des informations complexes.
Le reste du code métier dans un service, et les Contrôleurs se chargent d'appeler les Services, et gèrent l'affichage en envoyant des données à la Vue.

[Guldil]

Merci beaucoup, je comprends mieux grâce à ton explication, je n'avais pas compris en fait que la Repository c’était du niveau BDD et que le service etait métier. Je vais donc garder cette approche en tête, m'inspirer de ton exemple Service dans la FAQ et celui de bilbot pour le Repository.