It is generally a good idea to wrap business logic into services. Often, such services methods use doctrine’s repositories to operate on data storage. Injecting whole EntityManager service is a very popular approach, but it isn’t the most elegant way I could think of. EntityManager works only as a factory in that case and could lead to usage of other repositories, which might end up with too many responsibilities of given service.
The better way is to inject single repositories, using a factory-service mechanism, provided by the Dependency Injection Container.f

Services.xml configuration consists of repository declaration and bespoken service:
[gist id=”9b751c3f1d409af3fe110fd85905b11f”]
Below we have an implementation of our custom entity repository. It doesn’t do anything special at this moment but is prepared to be developed in the future.
[gist id=”3249b2e9f1d2beacfae39f374d0fbf7e”]
The last but not least our service, which will make use of the injected repository.
[gist id=”df4d044143260ee70dbe7dc8c58924a4″]
One more thing: I suggest to type hint to EntityRepository because it will be ready to provide default repository (not your own). This also decouples service from repository implementation, which is a good thing in terms of the Dependency Inversion principle. UPDATE 2013-10-15 After receiving very useful feedback in the comments below, I have something to add. It’s better to have a repository which implements your own interface, but this interface should extend ObjectRepository interface from Doctrine\Common\Persistence namespace. With this approach repository’s contract (custom methods) are specified in an interface and this interface also denotes ObjectRepository behaviours (as it extends this interface). Moreover, this repository extends the EntityRepository, which gives it all the needed things to interact with the query builder and entity manager. One disadvantage is that the interface is coupled with Doctrine Persistance, but it’s okay in this case.

[gist id=”1201aee7b42918f5ccf3fa37cd0513bf”]

It is generally a good idea to wrap business logic into services. Often, such services methods use doctrine’s repositories to operate on data storage. Injecting whole EntityManager service is a very popular approach, but it isn’t the most elegant way I could think of. EntityManager works only as a factory in that case and could lead to usage of other repositories, which might end up with too many responsibilities of given service.
The better way is to inject single repositories, using a factory-service mechanism, provided by the Dependency Injection Container.

Services.xml configuration consists of repository declaration and bespoken service:

[gist id=”069ff05cc057fb797ff29e7780ac8742″]

Below we have an implementation of our custom entity repository. It doesn’t do anything special at this moment but is prepared to be developed in the future.

[gist id=”h7e6103c0117a55d078e8e6d9b95505c4″]

The last but not least our service, which will make use of the injected repository.

[gist id=”521ae30025367c1550cf2422efcc8031″]

One more thing: I suggest to type hint to EntityRepository because it will be ready to provide default repository (not your own). This also decouples service from repository implementation, which is a good thing in terms of the Dependency Inversion principle.