Le 31/01/2014 16:00, Sebastian Krebs a écrit :
2014-01-31 Jasper N. Brouwer <[email protected]
<mailto:[email protected]>>:
Hi Sebastian,
EntityRepository::getEntityManager() is there to use within the
EntityRepository, but it's not the place to access it from outside
of the EntityRepository.
Somewhere in the configuration/bootstrap phase of your application
you create an EntityManager and store it so you can use it. In
frameworks using dependency injection, you can fetch the
EntityManager from the dependency container. Other frameworks
might use a registry where you can fetch it from.
Think of it this way: If you want to get the EntityManager from an
EntityRepository, you first need to get that EntityRepository from
the EntityManager. So you'll be running in circles this way ;)
Thanks for your answer.
That depends on where this "get that EntityRepository from the
EntityManager" happens, because when using dependency inject the
service-locator-like behaviour from getRepository() doesn't look
really nice. Instead I've defined the repository itself as a service
(with getRepository() as factory-method, but thats an implementation
detail ;))
class UserManager {
public function __construct (UserRepository $ur, ObjectManager $manager)
{
// ..
}
public function createuser ($name) {
$class = $this->ur->getClassName();
$user = new $class($name);
$this->userObjectManager->persist($user);
$this->userObjectManager->flush();
}
}
(aside: UserRepository would be an interface (if it exists))
As you can see, I always have to carry around both. If a class needs
more than on repository, at least theoretically I must expect, that
both uses different ObjectManager-instances, which ends up with
2*[number of repositories] parameters (not counting the not-Doctrine
related dependencies ;))
Don't get me wrong: Thats not the most serious problem I have right
now. It's just, that I wonder, if there is a rationale idea behind
that. Actually I would even prefer, if it would just expose the most
common methods (meaning "persist()" and maybe "flush()") instead of
the whole manager-instance.
The repository is about querying, not about persisting or flushing.
Exposing them would mix the responsibilities of the class.
And exposing getEntityManager publicly has the same drawback. If your
class needs to use the manager, inject it as a dependency instead of
using the repository as a service locator for the manager
--
Christophe | Stof
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/groups/opt_out.
