Skip to content

Commit 4ca4292

Browse files
committed
[best practice] add configuration.rst
1 parent d24ac09 commit 4ca4292

File tree

1 file changed

+164
-0
lines changed

1 file changed

+164
-0
lines changed

best_practices/configuration.rst

Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
設定
2+
=============
3+
4+
設定は、大抵、アプリケーション内の別々の部分(例えば、インフラとユーザー権限のような)と別々の環境
5+
(開発環境、プロダクション環境)に関連しています。
6+
そこで、 Symfony はアプリケーションの設定を3つの部分に分けて考えるようにしています。
7+
8+
インフラに関係する設定
9+
------------------------------------
10+
11+
.. best-practice::
12+
13+
インフラに関係する設定オプションは ``app/config/parameters.yml`` ファイルに定義しましょう。
14+
15+
デフォルトの ``parameters.yml`` ファイルはそうなっており、データベースとメールサーバーの設定を定義しています。
16+
17+
.. code-block:: yaml
18+
19+
# app/config/parameters.yml
20+
parameters:
21+
database_driver: pdo_mysql
22+
database_host: 127.0.0.1
23+
database_port: ~
24+
database_name: symfony
25+
database_user: root
26+
database_password: ~
27+
28+
mailer_transport: smtp
29+
mailer_host: 127.0.0.1
30+
mailer_user: ~
31+
mailer_password: ~
32+
33+
# ...
34+
35+
36+
このオプションは ``app/config/config.yml`` では定義されていません。というのも、アプリケーションの振る舞いに
37+
全く関係がないからです。
38+
つまり、アプリケーションは、オプションが正しく設定されている限りでは、データベースの場所やユーザー名や
39+
パスワードに関心を持たないのです。
40+
41+
デフォルトのパラメータ
42+
~~~~~~~~~~~~~~~~~~~~~~~~
43+
44+
.. best-practice::
45+
46+
アプリケーションの全てのパラメータを ``app/config/parameters.yml.dist`` に定義しましょう。
47+
48+
バージョン2.3以降、 Symfony には ``parameters.yml.dist`` という設定ファイルが含まれており、アプリケーションの
49+
設定で使われるデフォルトのパラメーターリストが保存されています。
50+
51+
新しい設定パラメータを定義したなら、このファイルにもそのパラメータを追加して、バージョン管理に反映させましょう。
52+
開発者がプロジェクトをアップデートした時やサーバーにデプロイした時に、 デフォルトの ``parameters.yml.dist`` と
53+
ローカルの ``parameters.yml`` の差分の有無を Symfony が自動的に調べます。
54+
もし差分があれば、 Symfony は新しいパラメータの値を尋ね、その値を ``parameters.yml`` に追記します。
55+
56+
アプリケーションに関する設定
57+
---------------------------------
58+
59+
.. best-practice::
60+
61+
アプリケーションの振る舞いに関する設定は ``app/config/config.yml`` に定義しましょう。
62+
63+
64+
``config.yml`` ファイルには、メール通知の送信元や `feature toggles`_ のような、アプリケーションの振る舞いを
65+
変える設定が含まれます。
66+
このようなオプション値を ``parameters.yml`` ファイルに定義してしまうと、サーバーごとに変える必要はない設定まで
67+
サーバーごとに設定しなかればならなくなります。
68+
69+
``config.yml`` に定義されている設定オプションは、大抵、 `execution environment`_ によって変わります。
70+
そこで、 Symfony には ``app/config/config_dev.yml`` と ``app/config/config_prod.yml`` があり、環境ごとに
71+
別の値を設定できるようになっているのです。
72+
73+
定数か、設定オプションか
74+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
75+
76+
アプリケーションの設定をするときに最もありがちなミスは、ページ分割の1ページあたりの件数のような、滅多に
77+
変更しない値をオプションとして定義することです。
78+
79+
.. best-practice::
80+
81+
滅多に変更しないオプションは定数として定義しましょう。
82+
83+
設定オプションを定義する伝統的な方法の結果として、多くの Symfony アプリケーションで下のようなオプションが
84+
定義されています。ブログホームページに表示する投稿の数を制御するオプション値です。
85+
86+
.. code-block:: yaml
87+
88+
# app/config/config.yml
89+
parameters:
90+
homepage.num_items: 10
91+
92+
この類いのオプションを最後に変更したのはいつだったか自問してみると、おそらく *一度も変更したことがない* という
93+
答えが出るでしょう。変更しない設定を設定オプションにするのは無駄です。このような値は定数として定義するのが良い
94+
でしょう。
95+
例えば、 ``Post`` エンティティの ``NUM_ITEMS`` 定数として定義するのです。
96+
97+
.. code-block:: php
98+
99+
// src/AppBundle/Entity/Post.php
100+
namespace AppBundle\Entity;
101+
102+
class Post
103+
{
104+
const NUM_ITEMS = 10;
105+
106+
// ...
107+
}
108+
109+
定数として定義する方式の主なメリットは、値をアプリケーション内のどこでも利用できることです。パラメータとして
110+
定義してしまうと、 Symfony のDIコンテナにアクセスできる場所でしか値を利用できませんでした。
111+
112+
例えば、定数は ``constant()`` ヘルパーを利用して Twig テンプレートの中でも使うことができます、
113+
114+
.. code-block:: html+jinja
115+
116+
<p>
117+
最新の投稿から {{ constant('NUM_ITEMS', post) }} 件表示しています。
118+
</p>
119+
120+
コンテナのパラメータを取得できない Doctrine のエンティティやレポジトリからも値を利用できます。
121+
122+
.. code-block:: php
123+
124+
namespace AppBundle\Repository;
125+
126+
use Doctrine\ORM\EntityRepository;
127+
use AppBundle\Entity\Post;
128+
129+
class PostRepository extends EntityRepository
130+
{
131+
public function findLatest($limit = Post::NUM_ITEMS)
132+
{
133+
// ...
134+
}
135+
}
136+
137+
定数で設定を定義することの唯一の弱点として、テストの時に簡単に値を上書きすることができないので、注意してください。
138+
139+
セマンティックな設定(利用してはいけません)
140+
--------------------------------------------
141+
142+
.. best-practice::
143+
144+
バンドルの設定をセマンティックなDI設定として定義しないようにしましょう。
145+
146+
`How to Expose a semantic Configuration for a Bundle`_ で説明されているように、 Symfony のバンドルには設定の方法が
147+
2つあります。 ``services.yml`` を使った通常の設定と、特別な ``*Extension`` クラスを使ったセマンティックな設定です。
148+
149+
セマンティックな設定は強力で、設定項目のバリデーションのような役立つ機能もありますが、セマンティック設定を定義する
150+
のにかかる作業が多すぎて、サードパーティのバンドルとして再利用されないバンドルを作る場合には釣り合いが取れないのです。
151+
152+
センシティブなオプションを完全に Symfony の外に追い出す
153+
--------------------------------------------------------
154+
155+
データベースの接続情報のようなセンシティブなオプションを設定するときには、 Symfony のプロジェクトの外部に保存し、
156+
環境変数を利用して読み込む方式も推奨します。
157+
この方式をどのようにして実現するのかについては、 `How to Set external Parameters in the Service Container`_ を
158+
参照してください。
159+
160+
.. _`feature toggles`: http://en.wikipedia.org/wiki/Feature_toggle
161+
.. _`execution environment`: http://symfony.com/doc/current/cookbook/configuration/environments.html
162+
.. _`constant() function`: http://twig.sensiolabs.org/doc/functions/constant.html
163+
.. _`How to Expose a semantic Configuration for a Bundle`: http://symfony.com/doc/current/cookbook/bundles/extension.html
164+
.. _`How to Set external Parameters in the Service Container`: http://symfony.com/doc/current/cookbook/configuration/external_parameters.html

0 commit comments

Comments
 (0)