When I have a service that needs a Repository and/or (Entity/Document)Manager, I inject the Manager. From the Manager I can get the Repository I need. This way I can simple inject 1 dependency (the Manager), regardless of how many repositories are actually used. I also don't need to implement Repositories as services (in order to inject them).
This however makes it impossible to inject say 2 Repositories, which could use 2 different Managers, but the service that gets them injected doesn't (have to) know about those 2 Managers. In my case I have to inject both Managers explicitly. (Usually I don't literally inject 2 Managers, but inject a Manager and a service that uses another Manager.) But I've never seen this as an issue, and I'm curious about a use-case you need this for. I can't really think of one (but that doesn't mean those cases don't exist). About "the repository is about querying": I agree here in the following sense: I use Repositories mainly for read queries, and perform persists and flushed outside of Repositories. But when I'm in need of insert, update, etc queries (for example batch updates) I put those queries in Repositories to. -- Jasper N. Brouwer (@jaspernbrouwer) On 31 Jan 2014, at 16:00, Sebastian Krebs <[email protected]> wrote: > 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. > > Regards, > Sebastian -- 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.
