Where to place business logic in Symfony2?

There are two main approaches regarding on where to put the business logic: the SOA architecture and the domain-driven architecture. If your business objects (entities) are anemic, I mean, if they don’t have business logic, just getters and setters, then you will prefer SOA. However, if you build the business logic inside your business objects, then you will prefer the other. Adam Bien discusses these approaches:

Domain-driven design with Java EE 6: http://www.javaworld.com/javaworld/jw-05-2009/jw-05-domain-driven-design.html

Lean service architectures with Java EE 6: http://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html

It’s Java, but you can get the idea.

Is the refactor a good one? If not, what would be a better way?

One of the best framework practices is using param converters to directly invoke an entity from user request.

Example from Symfony documentation:

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;/** * @Route("/blog/{id}") * @ParamConverter("post", class="SensioBlogBundle:Post") */public function showAction(Post $post){}

More on param converters:

http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html

Robert C. Martin (the clean code guy) says in his new book clean architecture, that you should put your business logic independently from your framerwork, because the framework will change with time.

So you can put your business logic in a seperate folder like App/Core or App/Manager and avoid inheretence from symfony classes here:

<?phpnamespace App\Core;class UserManager extends BaseManager implements ManagerInterface{}