5分でわかる

Symfony Best Practices

 

アシアル株式会社 社内勉強会

2015/12/10

宇都宮　諒

Symfony Best Practicesとは

  • Symfonyを使う上でのお作法集
  • 必ずしもこれに従う必要はないが、設計に迷った時の指針になる
  • Best Practicesに合わせるために、既存のアプリケーションの設計を変える必要はない

本資料について

  • Best Practicesの簡略版
  • 対応するSymfonyのバージョンは2.7

プロジェクトの作成方法

  • Symfony Installerを使用してプロジェクトを作成する
    • Symfony Installerは、symfony.comからアーカイブをダウンロードする
      • composerより高速
      • GitHubのリクエスト制限にも引っかからない
  • アプリケーションには、AppBundleというBundleを1つだけ作成する​
    • 他のプロジェクトと共有しないビジネスロジックはAppBundleにまとめる
    • 他のプロジェクトでも再利用したい部分は独自にBundle化してもOK

設定

  • app/config/parameters.yml
    • ​DB設定等、動作の基盤となる設定
    • 環境ごとに変わる可能性がある値
  • ​app/config/parameters.yml.dist
    • ​環境ごとの変化がない値
  • ​app/config/config.yml
    • ​アプリケーションの振る舞い(dev/prod等)に関する設定
  • ​変更の可能性が低い値は、ymlではなくクラス定数で定義する

ビジネスロジック

  • サービスコンテナの設定はymlで記述する
    • app/config/services.yml
  • Doctrineのエンティティのマッピングはアノテーションを使用する

コントローラー

  • アプリケーションのコントローラーには、FrameworkBundleのControllerを継承させる
    • ​コントローラーでフレームワークとの結合度を低めても意味が無い
  • ルーティングはアノテーションを使う
  • ​@Templateアノテーションを使うべきではない​
  • 複雑なデータ取得が必要な場合、@ParamConverterアノテーションの使用を推奨する

テンプレート

  • テンプレートエンジンはTwigを使う
  • app/Resources/views/ にテンプレートファイルを置く
  • テンプレート名にはlower case+snake caseを使う
    • the_template_name.html.twig
  • Twig拡張を作る場合、AppBundle/Twigに定義して、app/config/services.yml で設定する

フォーム

  • フォームはPHPクラスとして定義する
    • FormBuilderによる動的な組み立ては使わない
  • ボタンはフォームクラスやコントローラーではなくテンプレートで追加する
  • 独自フィールドには app_ という接頭辞をつける

国際化

  • 翻訳ファイルにはXLIFF形式を使う
    • XLIFFはXMLを拡張した、翻訳のためのフォーマット
  • 翻訳ファイルはapp/Resources/translations/に置く
  • 翻訳ファイルのメッセージのキーには、コンテンツ自身ではなく、コンテンツの内容を示す文字列を指定する

セキュリティ

  • 認証ファイアウォールは1つだけ設置すべき
    • 2つ以上のログイン手段がある場合は例外
  • ユーザーのパスワードの暗号化にはbcryptを使うべき
  • 認可は以下の方式で行う
    • security.ymlのaccess_controlを使ってURLのパターンマッチでアクセスコントロールを行う
    • コントローラーでは@Securityアノテーションを使う

アセット

  • CSS、JavaScript、画像ファイル等はweb/ディレクトリに置く
  • Asseticを使ってアセットのコンパイルやminifyを行う
    • gulp等のフロントエンドツールを別に使っているなら、Asseticを使う必要はない

テスト

  • 機能テストを作成し、少なくともページが正常にロードされるかテストすべき
    • 必要に応じて、より詳細な内容もテストする
  • 機能テストで使用するURLはハードコードすべき

※ユニットテスト（=ビジネスロジックのテスト）はSymfonyとは独立したものなので、Symfonyはユニットテストの実装方法については意見を持たない

One More Thing

  • SymfonyにBest Practicesがあるように、DoctrineにもBest Practicesがある！
  • そんなに大したことは書いてないし、分量も少ない
  • ここには書いてないが重要なBest Practiceもある
  • 例：
    • プレースホルダーを使う
    • 読み取り専用のデータ取得時はオブジェクトではなく配列かスカラーでハイドレーションする
    • QueryBuilderでは文字列ではなくexpr()メソッドを使う
    • （使える場面では）Referenceを使う

Doctrine Best Practices

  • リレーションはできるだけ減らす
  • 複合キーを避ける
  • イベントの利用は慎重に
  • CASCADEの利用は慎重に
  • テーブル・カラム名等に非ASCII文字は使わない
  • コレクションはコンストラクタで初期化する
  • 外部キーのフィールドをマッピングしない
  • できるだけ明示的にトランザクションを使う
    • Doctrineは暗黙的にトランザクションを行うが、本当に必要なところでは明示的にやるべき

おわりに

  • 本資料では、詳細を省いている部分も多いです
  • 本資料をとっかかりにして、Best Practicesを通読してみてください

ご清聴ありがとう

ございました