配置

配置通常包含了项目中不同的部分(基础架构和安全证书)和不同的环境(开发环境和生产环境)。这就是为什么Symfony推荐你将你的配置文件分成三个部分。

关系到基础架构的配置

最佳实践

有关基础架构的配置定义在app/config/parameters.yml中。

# app/config/parameters.yml
parameters:
    database_driver:   pdo_mysql
    database_host:     127.0.0.1
    database_port:     ~
    database_name:     symfony
    database_user:     root
    database_password: ~

    mailer_transport:  smtp
    mailer_host:       127.0.0.1
    mailer_user:       ~
    mailer_password:   ~

    # ...

这些选项不要定义在app/config/config.yml中,因为这些配置和你的应用程序业务无关。换句话说就是你的应用压根不关心数据库放在哪儿,或者用来访问数据库的安全证书,只要它被正确的配置好就行。

标准参数

最佳实践

将所有的参数定义在app/config/parameters.yml.dist中。

自2.3开始,symfony包含了一个叫parameters.yml.dist的配置文件,里面包含了所有的参数配置选项。

每当你定义了新的参数时,别忘了在这个文件里也添加进去,然后提交到版本管理系统里。在之后的日子里,一旦有他人更新或者部署这个项目的时候,Symfony会检查这个标准的参数文件和本地的参数文件,当发现有不同时,Symfony会要求你提供新的参数,并且添加到本地项目的parameters.yml文件中。(译者觉得因为parameters.yml中的很多参数是不易公开的,所以在Symfony项目里,ignore文件中忽略了parameters.yml,但是总要有个文件告诉大家该怎么配置项目参数,这就是parameters.yml.dist的作用)。

应用相关的配置

最佳实践

将所有与应用行为有关的配置定义在app/config/config.yml中。

config.yml定义了有关应用程序行为的配置,例如发送邮件的通知,或者启用feature toggles。将这些值定义在config.yml中会给项目添加一个新的配置层,而这些配置并不会因为项目跑在不同的服务器上而改变。

在不同的环境下,config.yml中的配置也会发生变化,这就是为什么Symfony包含了app/config/configdev.yml和app/config/configprod.yml这两个配置文件。这样做可以让你在不同的环境下改写特定的配置。(比如给生产和开发环境连接不同的数据库)

常量VS配置选项

在配置应用程序时最常见的错误之一就是创建一个新的不变的值,例如分页显示中每页的显示个数。

最佳实践

使用常量来定义那些很少发生变化的配置选项。

如下配置就是很多Symfony应用所使用的传统方法,比如用来规定博客主页显示多少篇博文: ```

app/config/config.yml

parameters: homepage.num_items: 10 ```

如果你以前这么做过,想必你也永远不想改变这个值。为了一个不需要变动的值来设计一个配置选项是不必要的,我们建议你在项目中使用常量来定义这些值。你可以像如下代码这么做,直接在Post entity中定义一个NUM_ITEMS常量: ``` // src/AppBundle/Entity/Post.php namespace AppBundle\Entity;

class Post { const NUM_ITEMS = 10;

// ...

} ```

定义常量的优势在于你可以在项目中的任何地方使用该常量,而使用参数的话,你必须在能访问Symfony容器的情况下使用他们。

得益于constant() function,常量还可以在Twig模板中使用:

<p>
    Displaying the  most recent results.
</p>

而且Doctrine entity和repository可以容易的访问这些值,但是它们不能访问Symfony容器的参数:

namespace AppBundle\Repository;

use Doctrine\ORM\EntityRepository;
use AppBundle\Entity\Post;

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

使用常量的唯一缺点就是在测试时没那么方便的随意修改了。

语义式配置:NONONO!

最佳实践

不要为你的Bundle使用语义式依赖注入配置。

如何在Bundle内载入服务配置这篇文章中,我们提到了Symfony Bundle有两种方法来处理配置:通过service.yml来配置一般服务,和通过使用特定的Extension类来处理语义式配置。

虽然语义式配置很强大,它提供了一些优美的特性例如配置审核,但是对于一个不向第三方分享的Bundle来说,花这么多功夫显然是划不来的。

把有敏感信息的配置从Symfony中全部移除

在处理有敏感信息的配置时,例如数据库访问用户和密码,我们建议你将存放在Symfony项目之外的地方,通过环境变量访问他们。想了解如何实现吗?去这里:如何在服务容器内设置外部参数

上一章:创建项目

下一章:组织业务逻辑