How to get entity manager for Doctrine entity with Symfony 2.1 from inside controller

Question

How can I get an entity manager from inside a controller with latest Symfony and Doctrine?

The way described in "The Book" flagged as deprecated now. What is a modern (proper) way to do this?

public function someAction()
{
    // getEntityManager() from Doctrine\Bundle\DoctrineBundle\Registry is deprecated
    $entityManager = $this->getDoctrine()->getEntityManager();
    ...
}

Solution

Use $this->getDoctrine()->getManager() instead.

Actually, it's best not to make controllers aware of the persistence layer you're using. That stuff should be moved to the Service Layer to abstract the way the data is persisted.

Comments

[Mohammad AbuShady]

Actually i didn't know about the deprecated method till recently, it was noted as a warning in the symfony2 debug page, and it also told me what is the new method that I should use. So I'm guessing that most of the time you'll find the answer in the debug page.

[Gottlieb Notschnabel]

What do you mean? Should all database related methods be moved into the Service Layer? What's the benefit? The EntityManager is already in the Service Layer (I suppose). Or am I misunderstanding something? Can you give an example?

[ILikeTacos]

@Elnur I've seen similar statements like "You shouldn't do that in your controller" all over the place, but all of the answers fail to explain why. I know that controllers are framework specific and by persisting data in your controller your code is not as portable as it could be, but I haven't seen a concrete example of that.

[Elnur Abdurrakhimov]

@AlanChavez, it's all about reasons a unit of code can change. For example, if you switch from ORM to ODM, only the data access layer is supposed to change. If that change ripples to controllers, you've failed at separation of concerns. A unit of code — like a layer or a class — is supposed to change for one type of reasons only. Read some books on OO patterns and design. Also google SOLID.

[ILikeTacos]

Thanks for your answer! I more or less know what SOLID and unit of code is. However, what bugs me a bit is that even Symfony's docs encourage the practice to make your controllers aware of the persistence layer, see example here: symfony.com/doc/current/book/…

[Seer]

I think the Symfony docs aren't intending to encourage that practice, instead I think they're just there to use as a guide to show you the components necessary to complete a given task. Leaving it up to the developer to make the decisions for where logic should be.

[Elnur Abdurrakhimov]

@AlanChavez, given the average level of PHP developers, the target audience of Symfony docs is beginning-to-intermediate developers. It's easier to reference Doctrine right from the controllers in the docs instead of creating layers and layers that will complicate stuff for beginning developers. But if you're an advanced developer and comfortable with good OO approaches, you can figure out how to do layers yourself.

[Zennichimaro]

@ElnurAbdurrakhimov: I'm a beginner in php and symfony, but would like to learn and habituate the best practice from the beginning, do you have sample that shows the separation of concern? Thx!

[Dennis]

@Elnur, can you add more details? Does Controller implement getDoctrine()? I am uzing ZF2 modules, not full ZF2 stack and I am missing something . .. . For example, I get fatal errors for non-existent functions called getDoctrine() getEntityManager(). Where do they come from?