The Official Symfony Best Practice Guide

  • Tutorial
Fabien Potencier, the Symfony menter a few days ago, introduced a draft version of the best practice guide for developing applications using Symfony as a framework (I remind you that this is also a set of independent components).
We know how difficult it is to unlearn old habits and some tips will shock you, but following them you can develop applications faster, make them less complex and at the same time better.
In any case, it is worth remembering that these are just recommendations and your team is not obliged to follow them. You can continue to use your approaches, Symfony is flexible enough for any needs and this will never change.

Under the cut, I wrote out the main theses, most of them are argued in detail inside the book, in some "shocking" places, in addition to the thesis, there is a small explanation.

  • Always use Composer to install Symfony.
  • Create only one bundle for application logic. A bundle is an independent component that can later be reused. For example, your application has a UserBundle and a ProductBundle. Most likely the ProductBundle will not work correctly without the UserBundle, and this is not correct.
  • Environment parameters (database, logs) and applications are described in the file app/config/parameters.yml.
  • The default environment and application settings are described in app/config/parameters.yml.dist.
  • Describe unchanging parameters in constants (directly in app/config/parameters.yml).
  • The names of your services should be as short and simple as possible, ideally it should be one word (for example, slugger, geocoder).
  • Use YAML to define application services.
  • Using Doctrine ORM, define a schema using annotations. All configuration formats have the same performance.
  • Application controllers should inherit Symfony\Bundle\FrameworkBundle\Controller\Controller, use annotations for routing and caching whenever possible.
  • Do not use annotation @Template()to customize the template used by the controller. Annotation is useful, but works "magically", so it is recommended not to use it. Also, using this annotation slows down your application by 21ms.
  • Use automatic parameter conversion when it is useful and convenient
    /**
    * @Route("/{id}", name="admin_post_show")
    */publicfunctionshowAction(Post $post)

  • For template use Twig .
  • Store your templates in a directory app/Resources/views/.
  • For each form, create a class.
  • Add buttons in the template, not in the PHP code.
  • For transfers, use the XLIFF format.
  • Store translation files in app/Resources/translations/.
  • Always use keywords to translate, instead of text. For example, not Username, but label.username.
  • If your application has two authorization options, it is recommended to use one firewall, with the option enabled anonymous.
  • Use an algorithm bcryptto hash user passwords.
  • To automatically check permissions by URL, use access_control. Use annotation whenever possible @Security. In more complex situations, use the service security.context.
  • Store statics (assets) in a directory web/.
  • Use Assetic for statics processing, or other similar tools, for example GruntJS .
  • When using front-end frameworks such as AngularJS , you must separate the front-end and backend into two projects.
  • Write at least functional tests to verify that application pages load successfully. Hardcode the URL of the page, instead of using it UrlGenerator.

Also popular now: