Sont les dépositaires Doctrine2 un bon endroit pour sauver mes entités?

Question

Quand je lis docs sur les dépôts, il est souvent de travailler avec des entités et la collecte, mais d'une manière « lecture seule ».

Il n'y a jamais des exemples où les dépôts ont des méthodes telles que insertUser(User $user) ou updateUser(User $user).

Cependant, lors de l'utilisation SOA, service ne devrait pas travailler avec Entity Manager si (c'est vrai, non?):

1. doit mon service soit au courant de la EntityManager mondiale?
2. devrait savoir mon service seulement sur les dépôts de logiciels (disons, UserRepository & ArticleRepository)

De que les deux questions, l'autre, mon service devrait jamais explicitement persist() et flush() mes entités?

Answer 1

Oui, les dépôts sont généralement utilisés pour les requêtes uniquement.

Voici comment je le fais. La couche de service gère la persistance. La couche contrôleur connaît de la couche de service, mais ne sait rien de la façon dont les objets du modèle sont conservés ni où viennent-ils. Pour ce que les soins de la couche contrôleur demande la couche de service de persister et d'objets de retour - il ne se soucie pas comment il est réellement fait

.

La couche de service lui-même est parfaitement adapté à savoir sur la persistance de la couche:. Les gestionnaires d'entités ou documents, dépôts, etc

Voici un code pour le rendre plus clair:

class UserController
{
    public function indexAction()
    {
        $users = $this->get('user.service')->findAll();
        // ...
    }

    public function createAction()
    {
        // ...
        $user = new User();
        // fill the user object here
        $this->get('user.service')->create($user);
        // ...
    }
}

class UserService
{
    const ENTITY_NAME = 'UserBundle:User';

    private $em;

    public function __construct(EntityManager $em)
    {
        $this->em = $em;
    }

    public function findAll()
    {
        return $this->em->getRepository(self::ENTITY_NAME)->findAll();
    }

    public function create(User $user)
    {
        // possibly validation here

        $this->em->persist($user);
        $this->em->flush($user);
    }
}

Answer 2

Si vous jetez un oeil au modèle référentiel http://martinfowler.com/eaaCatalog/repository. html ,

il est indiqué que les dépôts utilise une "collection comme l'interface".

Plus tard, il est écrit « Les objets peuvent être ajoutés et supprimés du référentiel, car ils peuvent à partir d'une simple collection d'objets ».

Je ne dis pas cela est une bible, mais il est faux sur le plan conceptuel rien à voir un dépôt comme une collection que vous pouvez interroger. Mais comme il est une collection, vous pouvez ajouter, supprimer, ... En fait, la ObjectRepository devrait mettre en œuvre Doctrine \ Common Files \ Collection:)

D'autre part, le plus important est de ne pas se lit désordre et écrit, comme le dit CQS. C'est peut-être la raison pour laquelle ils ne permettaient pas directement, pour éviter les abus et lecture / écriture mix.

EDIT: J'aurais parlé flush. Cela devrait pas être fait dans le dépôt lui-même, car il pourrait briser la cohérence des transactions.

Vous feriez mieux de passer l'appel flush à quelque chose qui enveloppe toute la logique de transaction commerciale (un bus de commande gérer une f.e de commande?)

Answer 3

Well, how do you get your repository when not using the entityManager? After all, the entities are not going to be saved magically without a connection to the database, so your service must somehow be aware of any kind of connection.

I don't know about the SOA Services, but in my eyes it makes no difference at all if you use $_em->getRepository()->save($entity) or $_em->persist($entity). On the other hand, if you use flush in your repository, you might end up with way more queries than needed as your repository is now aware of the business logic.

I think there is a way to do this "the SOA way", but I guess it's not persisting the entities within the repository.