Good practice in symfony 2 (from personal experience)
Good day, dear habravchane. Today I saw an article on the Habré "Official Guide to Best Practices in Symfony" and realized that I have something to fix to add. To your attention a list of personal advice and an explanation of them.
Personally, I love annotations, but with experience I realized that they bring some discomfort. The fact is that the entire configuration cannot be transferred to annotations. There are 2 options left:
')
If you choose the second option, then with the growth of the project turns porridge. And your code has more annotations than logic. Excuses like “it is easier to find routes” are not accepted. Since if you scatter the configuration files correctly, you always know where the routes to certain controllers are located. I am already silent about the commands in the console, by the type route: debug, and the debugger, in which you can see the name of the action and the name of the route.
Bad example (as for me):
Immediately give a bad example, as arranged on the current project:
All classes of managers should be in the Manager folder, classes of the Repository repositories. If this is not done, then when 5-10 entities appear with their managers and repositories, life becomes “more fun”.
It's simple. In each separate page you will be able to redefine and load only those javascripts and styles that are needed. I also advise you to leave these blocks empty in the most basic template. And in the bundles when creating the main layout.html.twig fill them.
Even if the project is small, initially get used to storing configuration bundles in AppBundle / Resources /, and not in app / config. In app / links only. This mainly concerns routing and services.
Entities are best described in the configuration, for example, in AppBundle / Resources / config / doctrine / Entity.orm.yml, and generated using the doctrine: generate: entities command, which itself generates entity classes. When entity configs are in files, the classes themselves look cleaner. Also, you will be sure that there are no errors in them.
In the parameters.test file, specify the parameters of the test database into which the fixtures are loaded. So you will always be sure that you are testing the same data. Perhaps everything does just that, just on the current project I was faced with a lack of such practice.
Of course, these are all trivial things, but there are people who do not do this and because of this,martyrs and programmers who write after them suffer.
I would be glad if someone wrote their advice in the comments.
Added :
Use less annotations
Personally, I love annotations, but with experience I realized that they bring some discomfort. The fact is that the entire configuration cannot be transferred to annotations. There are 2 options left:
- Maximum in configuration files (for example, yml);
- A little bit in the files, a little bit in the annotations.
')
If you choose the second option, then with the growth of the project turns porridge. And your code has more annotations than logic. Excuses like “it is easier to find routes” are not accepted. Since if you scatter the configuration files correctly, you always know where the routes to certain controllers are located. I am already silent about the commands in the console, by the type route: debug, and the debugger, in which you can see the name of the action and the name of the route.
Bad example (as for me):
Managers and repositories to make in separate folders.
Immediately give a bad example, as arranged on the current project:
All classes of managers should be in the Manager folder, classes of the Repository repositories. If this is not done, then when 5-10 entities appear with their managers and repositories, life becomes “more fun”.
In templates, always define blocks with javascript and styles.
It's simple. In each separate page you will be able to redefine and load only those javascripts and styles that are needed. I also advise you to leave these blocks empty in the most basic template. And in the bundles when creating the main layout.html.twig fill them.
Bundle configurations stored in AppBundle / Resources
Even if the project is small, initially get used to storing configuration bundles in AppBundle / Resources /, and not in app / config. In app / links only. This mainly concerns routing and services.
Entity described in the configuration file
Entities are best described in the configuration, for example, in AppBundle / Resources / config / doctrine / Entity.orm.yml, and generated using the doctrine: generate: entities command, which itself generates entity classes. When entity configs are in files, the classes themselves look cleaner. Also, you will be sure that there are no errors in them.
For tests, create a separate database
In the parameters.test file, specify the parameters of the test database into which the fixtures are loaded. So you will always be sure that you are testing the same data. Perhaps everything does just that, just on the current project I was faced with a lack of such practice.
Of course, these are all trivial things, but there are people who do not do this and because of this,
I would be glad if someone wrote their advice in the comments.
Added :
- To register forms types in DI, but not to create through new (Otherwise form type extensions do not work) - to0n1
- Use lazy proxies for dependencies in twig extension (Otherwise, a full dependency tree is built for each request) - to0n1
- If possible, do not use traits in conjunction with annotations (it’s not possible to overlap annotations in a class using treit) - to0n1
Source: https://habr.com/ru/post/240327/
All Articles