Organize business logic in Symfony2 - symfony

Question

I'm converting a Symfony1 application to Symfony2, and I'm trying to follow Symfony2's best practices.
I have a problem with the business logic: In the old app, all the logic was in the controller (very fat controllers). I've moved it to entity repositories, but I'm not sure if this is the correct way (because, aside other things, I need to send emails, and this isn't working).
For example, the save function for a resource reservation manager (calendar) is:
Begin transaction
Validate that the given resource isn't used in the time-lapse I'm trying to save
If the data is correct and the resource is marked as "mandatory confirmation", an email is sent to all the users from the "confirmers" group
An email is sent to the current user telling him that the resource has been reserved correctly (and, if needed, telling that a "confirmer" must approve his reservation)
If all has worked well, commit the transaction. If any error has happened, rollback the transaction
As you can see, there is lots of business logic (this example is one of the easier modules), using multiple kind of entities, users, emailers, etc. So, how can I organize it? Should I put the business logic in an entity repository, or is better to use services? And for the emails, maybe it's better to send them from an event listener? And do you know where can I find some examples about this?

Answer 1

Simply make services to handle these tasks. For example; create a service that you can re-use, that's testable, for sending emails. Make the API as simple as it can be, and then you can use it in your controller.
The way I think about it is that the controller is ONLY there to send information around various services, and to handle what is output to the user. Anything else should be controlled via services, and the responses from those services.
It's not a bad thing to have small classes - your classes should aim to do one thing, and one thing well. If you split them up enough then they'll be easily testable, and easily reusable.
The Symfony Books are excellent resources for this kind of thing:
http://symfony.com/doc/current/book/service_container.html

Answer 2

You might find this article of Martin Fowler's useful. He says…
In general, the more behavior you find in the services, the more likely
you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind.
I suspect he and Eric Evans would implement your business logic using a DDD approach along the lines of…
class Resource
{
public function isUsedIn(TimePeriod $tp);
public function isMandatoryConfirmation();
}
class ReservationManager
{
public function save(Resource $r, TimePeriod $tp)
{
if (! $r->isUsedIn($tp) || $r->isMandatoryConfirmation()) {
// send email to all the users from the "confirmers" group
// send email to the current user
}
}
}
Unfortunately in my experience with Symfony2, this hasn't been done and the code has ended up inside services. Symfony acknowledge that business logic can be put into Doctrine entities but from my point of view, it is a bit of weasel offer.
Services are container aware and as such can easily access other services to perform other functions like sending emails, logging messages. Doctrine entries cannot access other services which means that like Seer, in our project, we end up using services.
If you like the idea of moving more of your business out from services, it isn't difficult however Doctrine & Symfony do not seem to support it out of the box :-(