トップ > Symfony > Symfony Best Practice 訳してみた - Chapter2 -

Symfony Best Practice 訳してみた - Chapter2 -

Symfony

Symfony Best Practiceの翻訳をしてます。 二日目です。

前回の記事

hanahirodev.hatenablog.com

※多分に意訳が入っておりますので、誤訳がある場合はご指摘ください。

※読み進めていくSymfony Best Practiceは 2016/10/23時点の情報です。

※写経をする場合は、事前にPHPの実行ができる環境をご用意ください。

3行まとめ

  • 2.X系まではcomposerでアプリケーションを作成していたが、今はインストーラを使うのが主流。
  • 開発したファイルはAppBundleに集約される。
  • 「Bundle=単品でも機能する部品」と捉えるべし。変更しないで移植できないBundleや他のBundleに依存しているBundleは、Bundleとはいえない。
第２章 Creating the Project
インストール

かつて、Symfonyプロジェクトは、PHPアプリケーションの構成管理ツールであるComposer*1で始めることができました。 しかし、現状ではご自身のプロジェクトを作り始める前にインストールされている、Symfonyインストーラを使うことをお勧めします。

Symfonyインストーラの使い方はこちらから確認できます。

Blogアプリの作成

さあ、Symfonyでアプリケーションを作成する準備が整いました。ファイルの作成及び、以下のコマンドを実行できるディレクトリに移動してください。

$ cd projects/
$ symfony new blog

# Windows
c:¥> cd projects/
c:¥projects¥> php symfony new blog
  • インストーラがうまく動かない、出力結果が表示されない場合、Phar エクステンション*2がインストール済みで、有効化されていることを確認してください。

上述のコマンドを実行することで、最新のstableバージョンのSymfonyをベースとしたプロジェクトとして、blogというディレクトリが作成されます。 インストーラは同時に、お使いのコンピュータの設定がSymfonyアプリケーションを実行するのに必要な条件を満たしているかもチェックします。 条件を満たしていない場合、修正するべき箇所の一覧が表示されます。

  • セキュリティの観点から、Symfonyではリリースごとに電子署名が付されています。インストールしたSymfonyの整合性を確認したい場合は、公開されているチェックサム*3を確認するか、こちら*4の手順からご確認ください。
アプリケーションの構築

ここまでで、アプリケーションのベースが出来たので、blog/ディレクトリを確認してみましょう。以下のようなディデクトリとファイルを確認できます。

blog/
├─ app/
│  ├─ config/
│  └─ Resources/
├─ bin
│  └─ console
├─ src/
│  └─ AppBundle/
├─ var/
│  ├─ cache/
│  ├─ logs/
│  └─ sessions/
├─ tests/
│  └─ AppBundle/
├─ vendor/
└─ web/

各ファイルとディレクトリ構造は、Symfonyがお勧めするアプリケーション構築のお作法を表しています。 各ディレクトリは以下のように使い分けられることを想定されています。

  • app/config/ にはすべての環境におけるあらゆる設定を配置します。
  • app/Resources/ にはアプリケーションで使用する画面テンプレートファイルと、翻訳ファイルを配置します。
  • src/AppBundle/ にはSymfony特有のコード(controllerやrouting)、ドメインのコード(例えばDoctrineクラス)、ビジネスロジックを配置します。
  • var/cache/ にはアプリケーションが生成したキャッシュファイルを配置します。
  • var/logs/ にはアプリケーションが生成したログファイルを配置します。
  • var/sessions/ にはアプリケーションが生成したセッションファイルを配置します。
  • tests/AppBundle/ には自動テスト(例えばUnitテスト)を配置します。
  • vendor/ はComposer がインストールしたアプリケーションに依存するファイルが格納されるので、一切手を触れるべきではありません。
  • web/ にはスタイルシート、JavaScript、画像ファイルなどフロントエンドの制御に必要なファイルを配置します。
アプリケーションバンドル

Symfony2.0がリリースされた時点では、ほとんどの開発者が自然と、symfony1系のお作法に則ってモジュールの分割をしていました。 これはUserBundle,ProductBundle,InvoiceBundleなどのように、多くのSymfonyアプリケーションが、バンドルを機能ごとにロジックを分割する手段として利用しながら開発していたためです。 しかし、バンドルは本来独立して再利用できるソフトウェアのパーツを意味します。仮に、UserBundleが"そのまま"他のSymfonyアプリケーションで利用できないのであれば、バンドルとして存在するべきではありません。さらに言えば、InvoiceBundleがProductbundleに依存しているのであれば、この２つをバンドルに分けるメリットが全くありません。

  • アプリケーションロジックはAppBundle１箇所にまとめましょう。

AppBundle1つに実装を集約させることで、簡潔で分かりやすいコードになります。

  • 共有されることがないので、AppBundleに(AcmeAppBundleのような)プレフィックスをつける必要はありません。
  • 新たにバンドルを作ることがあるとすれば、(controllerのような)ベンダー*5のバンドルをオーバーライドするときでしょう。詳しくはこちら

以上のことから、次に示す構造がSymfonyアプリケーションにおけるベストプラクティスに従った典型的な構成例です。

blog/
├─ app/
│  ├─ config/
│  └─ Resources/
├─ bin/
│  └─ console
├─ src/
│  └─ AppBundle/
├─ tests/
│  └─ AppBundle/
├─ var/
│  ├─ cache/
│  ├─ logs/
│  └─ sessions/
├─ vendor/
└─ web/
   ├─ app.php
   └─ app_dev.php
  • インストール時にAppBundleが作られませんでしたか？以下のコマンドからAppBundleを生成することができます。
$ php bin/console generate:bundle --namespace=AppBundle --dir=src --format=annotation --no-interaction
ディレクトリ構成の拡張

プロジェクトやインフラの要請により、Symfonyのデフォルトのディレクトリ構成に変更が必要になった場合、cache/, logs/, web/ のディレクトリは他のディレクトリに変更可能です。

感想

Bundleの分割やBundle内でのモジュール分割について、しっかり設計が必要。特にチームで開発している場合は、本章の内容を全員が共有していないと、思い思いのBundleが林立してしまい、アプリケーション全体の複雑性が増大する可能性があるだけでなく、似たような機能を複数箇所で実装することになり、開発効率が著しく低下してしまう。

(2016/10/30 更新)

next

hanahirodev.hatenablog.com

*1:https://getcomposer.org/

*2:http://php.net/manual/ja/intro.phar.php

*3:https://github.com/sensiolabs/checksums

*4:http://fabien.potencier.org/signing-project-releases.html

*5:訳注:3rdパーティ製のバンドルをカスタマイズしたいシチュエーションを想定しているようだ。