Son repositorios de Doctrine2 un buen lugar para guardar mi entidades?

Question

Cuando leí la documentación acerca de los repositorios, es a menudo el trabajo con las entidades y de cobro, pero en una "lectura única" manera.

Nunca hay ejemplos donde los repositorios se han métodos como insertUser(User $user) o updateUser(User $user).

Sin embargo, cuando el uso de SOA, el Servicio no se debe trabajar con el Gerente de la Entidad (que está bien, ¿no?) así:

1. En caso de que mi servicio sea consciente de la global EntityManager?
2. En caso de que mi servicio solo saben acerca de la utiliza de Repositorios (digamos, UserRepository & ArticleRepository)

Desde que ambas preguntas, la otra, si mi servicio de manera explícita persist() & flush() mi entidades ?

Answer 1

Sí, los repositorios generalmente se usan solo para consultas.

Así es como lo hago. los capa de servicio maneja la persistencia. La capa del controlador sabe de la capa de servicio, pero no sabe nada de cómo se persisten los objetos modelo ni de dónde vienen. Para lo que le importa a la capa del controlador es pedirle a la capa de servicio que persista y devuelva objetos, no le importa cómo se hace realmente.

La capa de servicio en sí es perfectamente adecuada para conocer la capa de persistencia: entidad o administradores de documentos, repositorios, etc.

Aquí hay algún código para dejarlo más claro:

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 echa un vistazo al patrón del repositorio http://martinfowler.com/eaacatalog/repository.html ,

Se afirma que los repositorios utilizan una "interfaz similar a la colección".

Más tarde, también se escribe "Los objetos se pueden agregar y eliminar del repositorio, ya que pueden de una simple colección de objetos".

No digo que esto sea una Biblia, pero conceptualmente no hay nada malo en ver un repositorio como una colección que puede consultar. Pero como es una colección, puede agregar, eliminar, ... de hecho, el objectroPository debe implementar doctrina Common Collection :)

Por otro lado, lo más importante es no desorden y escribe, como dice CQS. Esa es la razón por la que no permitieron directamente eso, para evitar abusos y leer/escribir mezcla.

Editar: debería haber hablado de flush. Esto debería no hacerse en el repositorio en sí, ya que podría romper la consistencia transaccional.

Será mejor que muevas el flush Llame a algo que envuelva toda la lógica de transacciones comerciales (¿un bus de comandos que maneja un comando FE?)

Answer 3

Bueno, ¿cómo se obtiene su repositorio cuando no usa el EntityManager? Después de todo, las entidades no se guardarán mágicamente sin una conexión a la base de datos, por lo que su servicio debe ser consciente de cualquier tipo de conexión.

No sé sobre los servicios SOA, pero a mis ojos no hace ninguna diferencia si usa $_em->getRepository()->save($entity) o $_em->persist($entity). Por otro lado, si usa Flush en su repositorio, puede terminar con muchas más consultas de las necesarias, ya que su repositorio ahora conoce la lógica de negocios.

Creo que hay una manera de hacer esto "la forma SOA", pero supongo que no persiste las entidades dentro del repositorio.