2014-01-31 Christophe COEVOET <[email protected]>: > Le 31/01/2014 16:00, Sebastian Krebs a écrit : > > > > > 2014-01-31 Jasper N. Brouwer <[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. >
Actually thats what my question is (somehow) about: When reading "Repository", just from the meaning of the word, I'd assume, that I not only can fetch something out of, but also can _push_ things into a repository. Maybe you have something to read (a link or so), why the responsibility is only about reading, but not writing? > > 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 > Thats what I'm doing right now, but it sometimes feel slightly cumbersome to always inject both. Regards, Sebastian > > -- > 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. > -- github.com/KingCrunch -- 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.
