Symfony2 Best Practices resume

Today I come across this Best practices in Symfony PDF:
http://symfony.com/doc/download-best-practices-book/

And I though about my own practices and where to apply some of this seen in the Best practices book.

Here is a brief 3 points summary of things I would like to change in my next projects:

1. Using Constant instead of variables in parameters.yml for those settings that rarely (or never) change
   // src/AppBundle/Entity/Post.php
   namespace AppBundle\Entity;
   class Post {
   const NUM_ITEMS = 10;

   }
   As pointed  in the book, doing so, the benefit is that you can access this constant from almost anywhere in your application. Including your twig templates. This is exactly the part I was not aware of:
   // src/AppBundle/Resources/views/Controller/mytwigtemplate.html.twig

   Displaying the {{ constant (‘NUM_ITEMS’ , post ) }} most recent results.
2. Keep your controllers Thin
   

   Symfony follows the philosophy of “thin controllers and fat models”. This means that controllers should hold just the thin layer of glue-code needed to coordinate the different parts of the application. As a rule of thumb, you should follow the 5-10-20 rule, where controllers should only define 5 variablesor less, contain 10 actions or less and include 20 lines of code or less in each action. This isn’t an exact science, but it should help you realize when code should be refactored out of the controller and into a service.

   That’s an easy to remember Rule:
   5   Variables or less
   10 Actions (Calls to services / Forms validation, etc)
   20 Lines of code

   Storing hundred of lines for an Action is always a bad idea specially if you are not the only one working for the project.  And it mostly denotes some bad architectural start, since I can imagine that a controller Action has so many lines has parts that are common and can be reused in another actions. So why not to put all related actions in a service ?

   In this same Chapter, has a best practice that I consider really important, and is in my point of view how an ideal Symfony oriented project should be thought:
   You should aggressively decouple your business logic from the framework while, at the same time, aggressively coupling your controllers and routing to the framework in order to get the
   most out of Symfony

3. Use eventListeners.
   As an example: Pre and Post Hooks
   If you need to execute some code before or after the execution of your controllers, you can use the EventDispatcher component to set up before/after filters

I find eventListeners one of the most cooles features. They are many use-cases, for example OneUp Uploader bundle uses it to handle File uploads, calling an event listener each time a file is uploaded through Ajax. Like that you can find many real use cases to do this kind of automatic things in the background.

If you like any other interesting part of this Symfony Best practices Book, feel free to join the conversation