配置参数

最佳实践

Define the infrastructure-related configuration options in the app/config/parameters.yml file.

默认参数¶

Since version 2.3, Symfony includes a configuration file called parameters.yml.dist, which stores the canonical list of configuration parameters for the application.

Whenever a new configuration parameter is defined for the application, you should also add it to this file and submit the changes to your version control system. Then, whenever a developer updates the project or deploys it to a server, Symfony will check if there is any difference between the canonical parameters.yml.dist file and your local parameters.yml file. If there is a difference, Symfony will ask you to provide a value for the new parameter and it will add it to your local parameters.yml file.

最佳实践

Define the application behavior related configuration options in the app/config/config.yml file.

常量 vs 配置¶

One of the most common errors when defining application configuration is to create new options for values that never change, such as the number of items for paginated results.

The traditional approach for defining configuration options has caused many Symfony apps to include an option like the following, which would be used to control the number of posts to display on the blog homepage:

# app/config/config.yml
parameters:
    homepage.num_items: 10

If you’ve done something like this in the past, it’s likely that you’ve in fact never actually needed to change that value. Creating a configuration option for a value that you are never going to configure just isn’t necessary. Our recommendation is to define these values as constants in your application. You could, for example, define a NUM_ITEMS constant in the Post entity:

// src/AppBundle/Entity/Post.php
namespace AppBundleEntity;

class Post
{
    const NUM_ITEMS = 10;

    // ...
}

The main advantage of defining constants is that you can use their values everywhere in your application. When using parameters, they are only available from places with access to the Symfony container.

Constants can be used for example in your Twig templates thanks to the constant() function:

<p>
    Displaying the {{ constant('NUM_ITEMS', post) }} most recent results.
</p>

And Doctrine entities and repositories can now easily access these values, whereas they cannot access the container parameters:

namespace AppBundleRepository;

use DoctrineORMEntityRepository;
use AppBundleEntityPost;

class PostRepository extends EntityRepository
{
    public function findLatest($limit = Post::NUM_ITEMS)
    {
        // ...
    }
}

The only notable disadvantage of using constants for this kind of configuration values is that you cannot redefine them easily in your tests.

最佳实践

Don’t define a semantic dependency injection configuration for your bundles.